OpenGL ES 3.0标准详解

需积分: 10 124 浏览量更新于2024-07-18 收藏 1.46MB PDF 举报

"OpenGL ES 3.0标准文档" OpenGL ES（OpenGL for Embedded Systems）是针对嵌入式设备的图形处理接口，它是一个轻量级、高效且针对移动平台的版本，用于在智能手机、平板电脑和其他资源有限的设备上实现高质量的3D图形。OpenGL ES 3.0是这个系列的一个重要版本，它在2.0的基础上引入了许多新特性，以提升图形处理能力并优化性能。此文档详细阐述了OpenGL ES 3.0图形系统的核心概念、工作方式以及实现它的要求。它面向的读者应具备基础的计算机图形学知识，包括基本的图形算法以及图形硬件的相关术语。 OpenGL ES 3.0的关键特性包括： 1. **浮点纹理与颜色缓冲**：支持浮点纹理，允许更精确的颜色表示和处理，这对于科学可视化、计算着色器等应用尤其重要。同时，颜色缓冲也支持浮点格式，提供更高的色彩精度。 2. **增强型顶点数据**：引入了新的顶点属性向量，如双精度顶点坐标，以及更多的顶点属性类型，提高了几何处理的灵活性。 3. **多个采样纹理**：支持多采样和超级采样纹理，用于实现高级抗锯齿效果，提升图像质量。 4. **统一的存储模型**：引入统一的缓冲对象和纹理存储模型，简化内存管理，并提高数据传输效率。 5. **计算着色器**（Compute Shader）：OpenGL ES 3.0首次引入计算着色器，使得GPU可以执行通用计算任务，扩展了其功能范围，对于物理模拟、图像处理等领域有巨大价值。 6. **增强的片段着色器**：增加了更多的内置函数和指令，如混合操作，以支持更复杂的后期处理效果。 7. **深度和模板缓冲增强**：提供了对深度测试和模板测试的更多控制，增强了场景的层次感和复杂性。 8. **纹理数组**：支持纹理数组，方便处理多层纹理数据，例如动画纹理或多个纹理贴图层。 9. **多视口渲染**：允许多个独立的视口同时渲染，适应多显示器或虚拟现实应用的需求。 10. **增强型帧缓冲对象**（FBO）：支持更多附件和格式，提高了离屏渲染的灵活性。 11. **增强的状态查询**：提供了更细粒度的状态查询，帮助开发者更好地监控和优化性能。 12. **扩展的错误处理**：改进了错误检测和报告机制，便于调试。 OpenGL ES 3.0标准文档还包含了对实现者的要求，确保跨平台的兼容性和一致性。任何Khronos Group的当前推广者、贡献者或采纳成员都可以无修改地复制和分发此规范的未修改版本，但不得为此收费，并且必须保持规格中的版权和商标信息完整。 OpenGL ES 3.0是移动设备3D图形编程的重要里程碑，它极大地扩展了图形处理能力，推动了移动游戏、应用程序和其他图形密集型应用的发展。

1.5. COMPANION DOCUMENTS 3

1.5 Companion Documents

1.5.1 OpenGL ES Shading Language

This speciﬁcation should be read together with a companion document titled The

OpenGL ES Shading Language. The latter document (referred to as the OpenGL

ES Shading Language Speciﬁcation hereafter) deﬁnes the syntax and semantics

of the programming language used to write vertex and fragment shaders (see sec-

tions 2.12 and 3.9). These sections may include references to concepts and terms

(such as shading language variable types) deﬁned in the companion document.

OpenGL ES 3.0 implementations are guaranteed to support versions 3.00 and

1.00 of the OpenGL ES Shading Language. All references to sections of that spec-

iﬁcation refer to version 3.00. The latest supported version of the shading language

may be queried as described in section 6.1.5.

1.5.2 Window System Bindings

OpenGL ES requires a companion API to create and manage graphics contexts,

windows to render into, and other resources beyond the scope of this Speciﬁcation.

There are several such APIs supporting different operating and window systems.

The Khronos Native Platform Graphics Interface or “EGL Speciﬁcation” de-

scribes the EGL API for use of OpenGL ES on mobile and embedded devices.

EGL implementations may be available supporting OpenGL as well. The EGL

Speciﬁcation is available in the Khronos Extension Registry at URL

http://www.khronos.org/registry/egl

The EAGL API supports use of OpenGL ES with iOS. EAGL is documented

on Apple’s developer website.

OpenGL ES 3.0.5 (November 3, 2016)

2.1. OPENGL ES FUNDAMENTALS 5

general, the effects of a GL command on either GL modes or the framebuffer must

be complete before any subsequent command can have any such effects.

In the GL, data binding occurs on call. This means that data passed to a com-

mand are interpreted when that command is received. Even if the command re-

quires a pointer to data, those data are interpreted when the call is made, and any

subsequent changes to the data have no effect on the GL (unless the same pointer

is used in a subsequent command).

The GL provides direct control over the fundamental operations of 3D and 2D

graphics. This includes speciﬁcation of parameters of application-deﬁned shader

programs performing transformation, lighting, texturing, and shading operations,

as well as built-in functionality such as texture ﬁltering. It does not provide a

means for describing or modeling complex geometric objects. Another way to

describe this situation is to say that the GL provides mechanisms to describe how

complex geometric objects are to be rendered rather than mechanisms to describe

the complex objects themselves.

The model for interpretation of GL commands is client-server. That is, a pro-

gram (the client) issues commands, and these commands are interpreted and pro-

cessed by the GL (the server). The server may or may not operate on the same

computer as the client. In this sense, the GL is network-transparent. A server may

maintain a number of GL contexts, each of which is an encapsulation of current

GL state. A client may choose to connect to any one of these contexts. Issuing

GL commands when the program is not connected to a context results in undeﬁned

behavior.

The GL interacts with two classes of framebuffers: window system-provided

and application-created. There is at most one window system-provided framebuffer

at any time, referred to as the default framebuffer. Application-created frame-

buffers, referred to as framebuffer objects, may be created as desired. These two

types of framebuffer are distinguished primarily by the interface for conﬁguring

and managing their state.

The effects of GL commands on the default framebuffer are ultimately con-

trolled by the window system, which allocates framebuffer resources, determines

which portions of the default framebuffer the GL may access at any given time, and

communicates to the GL how those portions are structured. Therefore, there are

no GL commands to initialize a GL context or conﬁgure the default framebuffer.

Similarly, display of framebuffer contents on a physical display device (including

the transformation of individual framebuffer values by such techniques as gamma

correction) is not addressed by the GL.

Allocation and conﬁguration of the default framebuffer occurs outside of the

GL in conjunction with the window system, using companion APIs described in

section 1.5.2.

OpenGL ES 3.0.5 (November 3, 2016)

2.1. OPENGL ES FUNDAMENTALS 6

Allocation and initialization of GL contexts is also done using these companion

APIs. GL contexts can typically be associated with different default framebuffers,

and some context state is determined at the time this association is performed.

It is possible to use a GL context without a default framebuffer, in which case

a framebuffer object must be used to perform all rendering. This is useful for

applications needing to perform offscreen rendering.

The GL is designed to be run on a range of graphics platforms with varying

graphics capabilities and performance. To accommodate this variety, we specify

ideal behavior instead of actual behavior for certain GL operations. In cases where

deviation from the ideal is allowed, we also specify the rules that an implemen-

tation must obey if it is to approximate the ideal behavior usefully. This allowed

variation in GL behavior implies that two distinct GL implementations may not

agree pixel for pixel when presented with the same input even when run on identi-

cal framebuffer conﬁgurations.

Finally, command names, constants, and types are preﬁxed in the GL (by gl,

GL_, and GL, respectively in C) to reduce name clashes with other packages. The

preﬁxes are omitted in this document for clarity.

2.1.1 Floating-Point Computation

The GL must perform a number of ﬂoating-point operations during the course of

its operation. In some cases, the representation and/or precision of such operations

is deﬁned or limited; by the OpenGL ES Shading Language Speciﬁcation for op-

erations in shaders, and in some cases implicitly limited by the speciﬁed format

of vertex, texture, or renderbuffer data consumed by the GL. Otherwise, the rep-

resentation of such ﬂoating-point numbers, and the details of how operations on

them are performed, is not speciﬁed. We require simply that numbers’ ﬂoating-

point parts contain enough bits and that their exponent ﬁelds are large enough so

that individual results of ﬂoating-point operations are accurate to about 1 part in

. The maximum representable magnitude for all ﬂoating-point values must be

at least 2

. x · 0 = 0 · x = 0 for any non-inﬁnite and non-NaN x. 1 · x = x · 1 = x.

x + 0 = 0 + x = x. 0

= 1. (Occasionally further requirements will be speciﬁed.)

Most single-precision ﬂoating-point formats meet these requirements.

The special values Inf and −Inf encode values with magnitudes too large to

be represented; the special value NaN encodes “Not A Number” values resulting

from undeﬁned arithmetic operations such as

. Implementations are permitted,

but not required, to support Inf s and NaN s in their ﬂoating-point computations.

Any representable ﬂoating-point value is legal as input to a GL command that

requires ﬂoating-point data. The result of providing a value that is not a ﬂoating-

point number to such a command is unspeciﬁed, but must not lead to GL interrup-

OpenGL ES 3.0.5 (November 3, 2016)

剩余362页未读，继续阅读

急躁码农

粉丝: 32
资源: 4

OpenGL ES 3.0标准详解

es_spec_3.2.pdf

es_spec_3.0.0 EN &OpenGL ES 2.0中文版

es_spec_3.0.withchanges

esapi-2.2.3.0.jar 下载

rtl8189es_linux_v5.8.9.tar.gz

Failed to start es_evdi_service.service: Unit es_evdi_service.service not found.

motionsensor_chip.ko ot_lt8618sx.ko ot_sample_ist.ko ot_spi.ko motionsensor_mng.ko ot_piris.ko ot_sensor_i2c.ko ot_es8388.ko ot_pwm.ko ot_sensor_spi.ko这些都是什么

simocode es usb驱动程序_sirius_usb_pc_cable_driver_v21228.rar

最新资源