OpenGL着色语言4.60.7版官方文档

需积分: 10 34 浏览量更新于2024-07-16 收藏 5.09MB PDF 举报

"OpenGL® Shading Language, Version 4.60.7 是一份由John Kessenich（Google编辑兼作者）以及Dave Baldwin和Randi Rost（Version 1.1作者）编写的参考手册，涵盖了OpenGL着色语言的最新版本。这份文档详细介绍了着色语言的各个方面，包括错误处理、语法约定、过时特性以及各种处理器的概述，如顶点处理器、镶嵌控制处理器、镶嵌评估处理器、几何处理器、片段处理器和计算处理器。内容还涉及基本的编译阶段、预处理器、变量与类型，如基本类型、作用域、存储限定符、布局限定符等，并深入探讨了精度、变异性、精确性以及特殊化常量等概念。" OpenGL® Shading Language (GLSL) 是OpenGL图形库的核心部分，用于编写着色器程序，这些程序在GPU上运行，负责处理图形渲染中的各个阶段。此文档的第1章介绍了变化、概述、错误处理和类型设置，强调了GLSL在不同版本间的更新和对错误处理的策略。其中，错误处理部分解释了编译和链接过程中可能出现的问题，以及如何通过GLSL的语义来预防和解决这些问题。第2章概览了不同的着色器处理器，它们在图形管道中扮演的角色如下： - 顶点处理器：处理输入顶点数据，生成最终用于绘制图元的坐标。 - 镶嵌控制处理器：用于自定义复杂的表面细分，提高细节水平。 - 镶嵌评估处理器：根据控制点的输出计算细分表面的每个部分。 - 几何处理器：接收顶点数据，生成或修改图元，如线段、三角形。 - 片段处理器：为像素着色，决定其颜色值。 - 计算处理器：执行通用计算任务，不直接与图形渲染关联。第3章详细阐述了GLSL的基本构建块，包括字符集、源字符串、预处理器指令（如宏定义和条件编译）、注释、令牌分类、关键字、标识符以及定义。这些是编写任何GLSL代码的基础。第4章深入探讨了变量与类型，涵盖了基本类型（如整型、浮点型、向量和矩阵）、变量的作用域、存储限定符（控制变量的生命周期和可见性）、布局限定符（用于指定硬件特定的布局）、插值限定符（用于控制片段着色器中数据的插值方式）、参数限定符、精度和精度限定符（指定变量的精度级别）、变异性（控制变量值的变化）、不变性限定符（确保着色器输入不会改变）、精确性限定符（用于确保计算的确定性）以及内存限定符和特殊化常量限定符。这份OpenGL® Shading Language, Version 4.60.7 参考手册为开发者提供了全面的GLSL编程指南，无论是在理解语言特性、编写高效的着色器代码，还是在调试和优化图形应用方面，都具有极高的参考价值。

Implementations must support macro-name lengths of up to 1024 characters. Implementations are

allowed to generate an error for a macro name of length greater than 1024 characters, but are also

allowed to support lengths greater than 1024.

#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 further restricted to expressions operating on literal

integer constants, plus identifiers consumed by the defined operator.

• Character constants are not supported.

The operators available are as follows.

Precedence Operator class Operators Associativity

1 (highest) parenthetical grouping ( ) NA

2 unary defined

+ - ~ !

Right to Left

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 )

Two tokens in a macro can be concatenated into one token using the token pasting (##) operator, as

is standard for C++ preprocessors. The result must be a valid single token, which will then be

subject to macro expansion. That is, macro expansion happens only after token pasting. There are

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

The semantics of applying operators to integer literals in the preprocessor match those standard in

the C++ preprocessor, not those in the OpenGL Shading Language.

Preprocessor expressions will be evaluated according to the behavior of the host processor, not the

processor targeted by the shader.

#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 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.

#pragma STDGL

The STDGL pragma is used to reserve pragmas for use by future revisions of this language. No

implementation may use a pragma whose first token is STDGL.

#pragma optimize(on)

#pragma optimize(off)

can be used to turn off optimizations as an aid in developing and debugging shaders. It can only be

used outside function definitions. By default, optimization is turned on for all shaders. The debug

pragma

#pragma debug(on)

#pragma debug(off)

can be used to enable compiling and annotating a shader with debug information, so that it can be

used with a debugger. It can only be used outside function definitions. By default, debug is turned

off.

Shaders should declare the version of the language they are written to. The language version a

shader is written to is specified by

#version number profile_opt

where number must be a version of the language, following the same convention as __VERSION__

above. The directive “#version 460” is required in any shader that uses version 4.60 of the

language. Any number representing a version of the language a compiler does not support will

cause a compile-time error to be generated. Version 1.10 of the language does not require shaders

to include this directive, and shaders that do not include a #version directive will be treated as

targeting version 1.10. Shaders that specify #version 100 will be treated as targeting version 1.00 of

the OpenGL ES Shading Language. Shaders that specify #version 300 will be treated as targeting

version 3.00 of the OpenGL ES Shading Language. Shaders that specify #version 310 will be treated

as targeting version 3.10 of the OpenGL ES Shading Language.

If the optional profile argument is provided, it must be the name of an OpenGL profile. Currently,

there are three choices:

core

compatibility

A profile argument can only be used with version 150 or greater. If no profile argument is provided

and the version is 150 or greater, the default is core. If version 300 or 310 is specified, the profile

argument is not optional and must be es, or a compile-time error results. The Language

Specification for the es profile is specified in The OpenGL ES Shading Language specification.

Shaders for the core or compatibility profiles that declare different versions can be linked

together. However, es profile shaders cannot be linked with non-es profile shaders or with es

profile shaders of a different version, or a link-time error will result. When linking shaders of

versions allowed by these rules, remaining link-time errors will be given as per the linking rules in

the GLSL version corresponding to the version of the context the shaders are linked under. Shader

compile-time errors must still be given strictly based on the version declared (or defaulted to)

within each shader.

Unless otherwise specified, this specification is documenting the core profile, and everything

specified for the core profile is also available in the compatibility profile. Features specified as

belonging specifically to the compatibility profile are not available in the core profile.

Compatibility-profile features are not available when generating SPIR-V.

There is a built-in macro definition for each profile the implementation supports. All

implementations provide the following macro:

#define GL_core_profile 1

Implementations providing the compatibility profile provide the following macro:

#define GL_compatibility_profile 1

Implementations providing the es profile provide the following macro:

#define GL_es_profile 1

The #version directive must occur in a shader before anything else, except for comments and white

space.

By default, compilers of this language must issue compile-time lexical and grammatical errors for

shaders that do not conform to this specification. Any extended behavior must first be enabled.

Directives to control the behavior of the compiler with respect to extensions are declared with the

#extension directive

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.

#line must have, after macro substitution, one of the following forms:

#line line

#line line source-string-number

where line and source-string-number are constant integer expressions. If these constant expressions

are not integer literals then behavior is undefined. After processing this directive (including its

new-line), the implementation will behave as if it is compiling at line number line and source string

number source-string-number. Subsequent source strings will be numbered sequentially, until

another #line directive overrides that numbering.



Note

Some implementations have allowed constant expressions in #line directives and

some have not. Even where expressions are supported the grammar is ambiguous

and so results are implementation dependent. For example, + #line +2 +2 // Line

number set to 4, or file to 2 and line to 2

When shaders are compiled for OpenGL SPIR-V, the following predefined macro is available:

#define GL_SPIRV 100

When targeting Vulkan, the following predefined macro is available:

#define VULKAN 100

3.4. Comments

Comments are delimited by /* and */, or by // and a new-line. The begin comment delimiters (/* or //)

are not recognized as comment delimiters inside of a comment, hence comments cannot be nested.

A /* comment includes its terminating delimiter (*/). However, a // comment does not include (or

eliminate) its terminating new line.

Inside comments, any byte values may be used, except a byte whose value is 0. No errors will be

given for the content of comments and no validation on the content of comments need be done.

剩余237页未读，继续阅读

3TV

粉丝: 60

OpenGL着色语言4.60.7版官方文档

The OpenGL Shading Language4.6,glspec46.core.pdf

The OpenGL ES Shading Language pdf

OpenGL着色语言英文第三版-OpenGL.Shading.Language.3nd.Edition.pdf

opengl 4.0 shading language cookbook daima

opengl 4 shading language cookbook third edition

opengl输出版本的函数

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

GLSL 4.50 is not supported.

qt c++获得显卡型号

最新资源