OpenGL 4.6 Shader语言参考手册：GLSLangSpec.4.60详解

需积分: 9 105 浏览量更新于2024-07-17 收藏 4.8MB PDF 举报

《OpenGL® Shading Language (GLSL) 4.60.6 参考手册》是针对OpenGL 4.6版本的专业编程指南，由John Kessenich（Google的编辑兼作者）和早期版本1.1的作者Dave Baldwin和Randi Rost共同编撰。此手册发布于2018年12月12日，提供了详尽的教程和规范，帮助开发者理解和掌握OpenGL的着色器编程。该手册的第一部分概述了GLSL的关键要素。"Introduction"章节列出了本次更新的主要变化，包括可能影响旧代码的新功能和改进。接着，"Overview"部分介绍了GLSL在OpenGL中的角色，着重区分了不同的处理器类型，如Vertex Processor、Tessellation Control/Evaluation Processor、Geometry Processor、Fragment Processor和Compute Processor，每个处理器都有其特定的着色任务。 "Basics"章节涵盖了GLSL的基础知识，如字符集和编译阶段，如何使用源字符串，以及预处理器的使用。这部分还介绍了注释、词汇、标识符的规则，以及定义的处理方式。对于程序员来说，理解这些基础知识至关重要，因为它们直接影响程序的可读性和执行效率。在变量和类型方面，"Variables and Types"章节深入探讨了基本数据类型，如整数、浮点数、向量和矩阵等，以及它们在内存中的存储方式。章节中还讨论了作用域、存储和布局资格、插值资格、参数资格、精度控制、不变量和精确度标记，以及内存访问资格。这些内容帮助开发人员正确地声明和管理变量，确保程序的正确性和性能。此外，手册还特别提到了"Specialization Constants"，这是一种用于优化着色器的特性，允许在编译时设置常量，从而减少运行时的计算开销。这对于编写高性能、适应不同场景的着色器非常重要。《GLSLangSpec.4.60.pdf》是一本全面且实用的GLSL编程指南，对于希望在OpenGL环境中实现高效图形渲染和计算的开发者来说，它是不可或缺的参考资料。通过学习和遵循其中的规则，开发者可以确保他们的着色器代码能够无缝融入现代OpenGL架构，并充分利用硬件的潜能。

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

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.

Removal of new-lines by the line-continuation character (\) logically occurs before comments are

processed. That is, a single-line comment ending in the line-continuation character (\) includes the

next line in the comment.

剩余216页未读，继续阅读

o西北狼o

粉丝: 0
资源: 4

OpenGL 4.6 Shader语言参考手册：GLSLangSpec.4.60详解

GLSL 中文手册 PDF

GLSLangSpec.Full.1.20.8

OpenGL.rar

安装opencv_python ==4.5.4.60

android socket 崩溃,Android：SocketTimeoutException：30000ms后无法连接到/103.24.4.60(端口80)...

如安装在D盘里面的opencv_contrib_python-4.5.4.60-cp39-cp39-win_amd64.whl

pip install opencv-contrib-python=4.5.4.60

opencv-contrib-python 4.5.4.60 opencv-python 4.7.0.72 opencv-python-headless 4.10.0.84如何将这三个都卸载/

python安装vc2

python终端安装cv2库

最新资源