OpenGL ES 3.20 Shading Language规范详解

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

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

《OpenGL ES® Shading Language》是针对移动和嵌入式平台的OpenGL ES图形处理语言版本3.20的一个详尽规范文档。该语言用于编写独立可编译的单元，即着色器，它们组合在一起构成一个程序。文档的主要目标是明确规定编程语法，并与OpenGL ES规范配合，定义了接口，使得应用程序能够管理和操作这些着色器。文档结构涵盖了多个关键部分： 1. **介绍**：章节1概述了文档的更新、整体目标以及错误处理策略。它强调了文档中的排版约定和兼容性考虑，确保读者能理解和使用这一语言。 2. **OpenGL ES着色语言概览**：这部分解释了不同处理器（如顶点处理器、 Tessellation Control/ Evaluation处理器、几何处理器、片段处理器和Compute处理器）在渲染过程中的角色。每个处理器对应不同的着色器类型，如Vertex Shader、Tessellation Shader等。 3. **基础**：这部分介绍了语言的基础元素，包括字符集、源代码字符串、版本声明、预处理器指令、注释、保留关键字、标识符、定义，以及编译过程的逻辑阶段。它着重于确保代码的可读性和一致性。 4. **变量和类型**：这部分深入探讨了各种类型的定义，包括基本类型（如float、int等）、变量的作用域、存储和布局资格、插值资格、参数资格、精度控制和精确性标志，以及变差量和不变量资格。这些内容对于正确使用和理解语言的关键特性至关重要。 4.1 **基本类型**：包括不同精度的浮点和整数类型，以及用于存储数据的不同方式。 4.2 **变量和作用域**：描述了变量如何在程序中定义、声明和作用范围，以及它们如何影响程序的执行。 4.3 **存储、布局和插值资格**：规定了如何指定变量在内存中的存储位置、数据访问方式以及在着色器的不同阶段如何被处理。 4.4 **参数和精度**：着重于着色器函数参数的管理，以及如何通过精度修饰符来控制计算的精确度。 4.5 **精确性**：讨论了如何使用`precise`修饰符来提高程序的正确性和性能优化。整个文档旨在帮助开发者编写高效、可移植的OpenGL ES着色器代码，以满足移动设备上的图形渲染需求。通过深入理解并遵循这些规则，程序员可以充分利用OpenGL ES的图形处理能力，实现丰富的视觉效果和高性能渲染。

资源详情

资源推荐

whitespace

opt

POUND whitespace

opt

VERSION whitespace number whitespace ES whitespace

opt

Tokens:

POUND #

VERSION version

ES es

3.4. Preprocessor

There is a preprocessor that processes the source strings as part of the compilation process.

The complete list of preprocessor directives is as follows.

#define

#undef

#if

#ifdef

#ifndef

#else

#elif

#endif

#error

#pragma

#extension

#line

The following operator is also available:

defined

Note that the version directive is not considered to be a preprocessor directive and so is not listed

here.

Each number sign (#) can be preceded in its line only by spaces or horizontal tabs. It may also be

followed by spaces and horizontal tabs, preceding the directive. Each directive is terminated by a

new-line. Preprocessing does not change the number or relative location of new-lines in a source

string.

The number sign (#) on a line by itself is ignored. Any directive not listed above will cause an error.

#define and #undef functionality are defined as is standard for C++ preprocessors for macro

definitions both with and without macro parameters.

The following predefined macros are available:

__LINE__

__FILE__

__VERSION__

GL_ES

__LINE__ will substitute a decimal integer constant that is one more than the number of preceding

new-lines in the current source string.

__FILE__ will substitute a decimal integer constant that says which source string number is

currently being processed.

__VERSION__ will substitute a decimal integer reflecting the version number of the OpenGL ES

Shading Language. The version of the shading language described in this document will have

__VERSION__ substitute the decimal integer 320.

GL_ES will be defined and set to 1. This is not true for the non-ES OpenGL Shading Language, so it

can be used to do a compile time test to determine if a shader is running on an ES system.

By convention, all macro names containing two consecutive underscores (__) are reserved for use

by underlying software layers. Defining such a name in a shader does not itself result in an error,

but may result in unintended behaviors that stem from having multiple definitions of the same

name. All macro names prefixed with “GL_” (“GL” followed by a single underscore) are also

reserved, and defining such a name results in a compile-time error.

It is an error to undefine or to redefine a built-in (pre-defined) macro name.

Implementations must support macro-name lengths of up to 1024 characters. It is an error to

declare a name with a length greater than this.

#if, #ifdef, #ifndef, #else, #elif, and #endif are defined to operate as is standard for C++

preprocessors except for the following:

• Expressions following #if and #elif are restricted to pp-constant-expressions as defined below.

• Undefined identifiers not consumed by the defined operator do not default to '0'. Use of such

identifiers causes an error.

• Character constants are not supported.

As in C++, a macro name defined with an empty replacement list does not default to '0' when used

in a preprocessor expression.

A pp-constant-expression is an integral expression, evaluated at compile-time during preprocessing

and formed from literal integer constants and the following operators:

Precedence Operator class Operators Associativity

1 (highest) parenthetical grouping ( ) NA

2 unary defined

+ - ~ !

Right to Left

Precedence Operator class Operators Associativity

3 multiplicative * / % Left to Right

4 additive + - Left to Right

5 bit-wise shift << >> Left to Right

6 relational < > <= >= Left to Right

7 equality == != Left to Right

8 bit-wise and & Left to Right

9 bit-wise exclusive or ^ Left to Right

10 bit-wise inclusive or | Left to Right

11 logical and && Left to Right

12 (lowest) logical inclusive or || Left to Right

The defined operator can be used in either of the following ways:

defined identifier

defined ( identifier )

There are no number sign based operators (e.g. no or @), no ## operator, nor is there a sizeof

operator.

The semantics of applying operators in the preprocessor match those standard in the C++

preprocessor with the following exceptions:

• The 2

operand in a logical and ('&&') operation is evaluated if and only if the 1

operand

evaluates to non-zero.

• The 2

operand in a logical or ('||') operation is evaluated if and only if the 1

operand

evaluates to zero.

• There is no boolean type and no boolean literals. A true or false result is returned as integer one

or zero respectively. Wherever a boolean operand is expected, any non-zero integer is

interpreted as true and a zero integer as false.

If an operand is not evaluated, the presence of undefined identifiers in the operand will not cause

an error.

#error will cause the implementation to put a compile-time diagnostic message into the shader

object’s information log (see section 7.12 “Shader, Program and Program Pipeline Queries” of the

OpenGL ES Specification for how to access a shader object’s information log). The message will be

the tokens following the #error directive, up to the first new-line. The implementation must treat

the presence of a #error directive as a compile-time error.

#pragma allows implementation-dependent compiler control. Tokens following #pragma are not

subject to preprocessor macro expansion. If an implementation does not recognize the tokens

following #pragma, then it will ignore that pragma. The following pragmas are defined as part of

the language.

Behavior Effect

enable Behave as specified by the extension

extension_name.

Warn on the #extension if the extension

extension_name is not supported.

Give an error on the #extension if all is

specified.

warn Behave as specified by the extension

extension_name, except issue warnings on any

detectable use of that extension, unless such use

is supported by other enabled or required

extensions.

If all is specified, then warn on all detectable

uses of any extension used.

Warn on the #extension if the extension

extension_name is not supported.

disable Behave (including issuing errors and warnings)

as if the extension extension_name is not part of

the language definition.

If all is specified, then behavior must revert

back to that of the non-extended core version of

the language being compiled to.

Warn on the #extension if the extension

extension_name is not supported.

The extension directive is a simple, low-level mechanism to set the behavior for each extension. It

does not define policies such as which combinations are appropriate, those must be defined

elsewhere. Order of directives matters in setting the behavior for each extension: Directives that

occur later override those seen earlier. The all variant sets the behavior for all extensions,

overriding all previously issued extension directives, but only for the behaviors warn and disable.

The initial state of the compiler is as if the directive

#extension all : disable

was issued, telling the compiler that all error and warning reporting must be done according to this

specification, ignoring any extensions.

Each extension can define its allowed granularity of scope. If nothing is said, the granularity is a

shader (that is, a single compilation unit), and the extension directives must occur before any non-

preprocessor tokens. If necessary, the linker can enforce granularities larger than a single

compilation unit, in which case each involved shader will have to contain the necessary extension

directive.

Macro expansion is not done on lines containing #extension and #version directives.

For each extension there is an associated macro. The macro is always defined in an implementation

that supports the extension. This allows the following construct to be used:

剩余186页未读，继续阅读

cuptee

粉丝: 0
资源: 5

OpenGL ES 3.20 Shading Language规范详解

The OpenGL ES Shading Language pdf

opengl4.5 shading language 规范

The OpenGL® Shading Language

OpenGL 4.0 Shading Language 实战指南

OpenGL ES高级着色器编程

OpenGL ES简介及环境搭建

OpenGL ES渲染管线优化技巧

OpenGL ES2.0中的着色器语言GLSL详解

OpenGL ES2.0中的光照和着色

opengl 4.0 shading language cookbook daima

opengl 4 shading language cookbook third edition

opengles应用开发实践指南pdf

opengl es2.0游戏与图形编程的代码怎么运行

移动端 qtopengl

Android OpenGL ES 基础原理

opengles2.0

metal shading language

how to fix this error: GLSL 4.50 is not supported?

最新资源