文件名称:
The OpenGL® Shading Language, Version 4.60.7
开发工具:
文件大小: 5mb
下载次数: 0
上传时间: 2019-10-15
详细说明：The OpenGL Shading Language, Version 4.60.7，可以作为参考手册5.2. Array Operations
112
53. Function calls
112
5.4. Constructors.........,,,,,,,,,
.112
5.5. Vector and Scalar Components and length
,,,.117
5.6. Matrix Components
119
5.7. Structure and Array Operations
120
5.8. Assignments
,,,,,,,,,,,,,,,,,,.121
5.9. Expressions
122
5.10. Vector and Matrix operations
124
5.11. Out-of-Bounds accesses
,,,,,,,,,,,,,,,..126
5.12. Specialization-Constant Operations
126
6. Statements and structure
128
6. 1. Function definitions
129
6.2. Selection
135
6.3. Iteration....,,,,,,,,
136
6. 4. Jumps
136
7. Built-In variables
..138
7. 1. Built-In Language variables
138
7. 2. Compatibility Profile vertex Shader Built-In Inputs
151
7. 3. Built-In constants
.152
7.4. Built-In Uniform state
154
7.5. Redeclaring Built-In Blocks
.157
8. Built-In Functions
159
8.1. Angle and Trigonometry Functions
160
8.2. Exponential Functions
,..161
8. 3. Common functions
,,,,..162
8.4. Floating-Point Pack and Unpack Functions
167
8.5. Geometric functions...,,,,,,,,,,,,,,,,,,,,,,,,,
168
8. 6. Matrix functions
.170
8.7 Vector Relational functions
171
8. 8. Integer functions
171
8.9. Texture functions
173
8.10. Atomic counter functions
,,,,..189
8.11. Atomic Memory functions
192
8.12. Image Functions
193
8.13. Geometry Shader Functions
196
8.14. fragment Processing Functions
197
8.15. Noise functions...,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
200
8. 16. Shader invocation control functions
201
8.17. Shader Memory Control Functions
201
8.18. Subpass-Input Functions
..,,,,..203
8.19. Shader Invocation Group Functions
203
9. Shading language grammar
205
10. Acknowledgments.,..
.218
11. Normative references
,,..219
12. Non-Normative SPIR-V Mappings.........
..,.220
12.1. Feature Comparisons
220
12.2. Mapping from glsl to SPIR-V
来指
221
Copyright o 2008-2018 The Khronos Group Inc. All Rights Reserved
This specification is protected by copyright laws and contains material proprietary to the khronos
Group, Inc. It or any components may not be reproduced, republished, distributed, transmitted,
displayed, broadcast, or otherwise exploited in any manner without the express prior written
permission of Khronos Group. You may use this specification for implementing the functionality
therein, without altering or removing any trademark, copyright or other notice from the
specification, but the receipt or possession of this specification does not convey any rights to
reproduce, disclose, or distribute its contents, or to manufacture, use, or sell anything that it may
describe, in whole or in part.
Khronos Group grants express permission to any current Promoter, Contributor or Adopter
member of Khronos to copy and redistribute UNMODiFiEd versions of this specification in any
fashion, provided that NO CHaRGE is made for the specification and the latest available update of
the specification for any version of the API is used whenever possible. Such distributed
specification may be reformatted AS LONG AS the contents of the specification are not changed in
any way. The specification may be incorporated into a product that is sold as long as such product
includes significant independent work developed by the seller. A link to the current version of this
specification on the Khronos Group website should be included whenever possible with
specification distributions
Khronos Group makes no, and expressly disclaims any, representations or warranties, express or
implied, regarding this specification, including, without limitation, any implied warranties of
merchantability or fitness for a particular purpose or noninfringement of any intellectual property.
Khronos group makes no, and expressly disclaims any, warranties, express or implied, regarding
the correctness, accuracy, completeness, timeliness, and reliability of the specification. Under no
circumstances will the khronos group, or any of its Promoters, Contributors or Members or their
respective partners, officers, directors, employees, agents, or representatives be liable for any
damages, whether direct, indirect, special or consequential damages for lost revenues, lost profits,
or otherwise, arising from or in connection with these materials
Khronos, Vulkan, SYCL, SPIR, WebGL, EGL, COLLADA, StreamInput, OpenvX, OpenKcam, glTF,
OpenKode, openvG, openWf, openSL es, OpenMAX, openMAX AL, openmaX Il and openmaX
DL are trademarks and WebCl is a certification mark of the Khronos group Inc. OpenCL is a
trademark of Apple Inc and OpenGl and OpenML are registered trademarks and the OpenGL ES
and OpenGL SC logos are trademarks of Silicon Graphics International used under license by
Khronos. All other product names, trademarks, and/or company names are used solely for
dentification and belong to their respective owners
Chapter 1 Introduction
This document specifies only version 4.60 of the OpenGL Shading Language (GLSL). It requires
VERSION to substitute 460, and requires #version to accept only 460. If #version is declared
with a smaller number, the language accepted is a previous version of the shading language, which
will be supported depending on the version and type of context in the API. See the normative
references for details on what language versions are supported
Previous versions of the OpenGL Shading Language, as well as the OpenGL ES Shading Language,
are not strict subsets of the version specified here, particularly with respect to precision, name
hiding rules, and treatment of interface variables. See the specification corresponding to a
particular language version for details specific to that version of the language
Throughout, when generating SPIR-V for consumption by the Vulkan API (see normative
references), this will be said to be targeting vulkan
While this specification and the OpengL Specification are normative for OpengL Shading
Language, for SPIR-V generation it is still the SPIR-V specification and the SPiR-v client API
specification that are normative for the generated SPIR-V See the normative references for further
detail
For SPir-v generation, the SPIR-v client API specifies the commands used to manipulate SPIR-V
shaders
Independent offline tool chains will compile glsl down to the spir-v intermediate language. sPir
V generation is not enabled with a #extension, #version, or a profile. Instead, use of Glsl for spir
V is determined by offline tool-chain use. See the documentation of such tools to see how to request
generation of SPIR-V for its client API
GLSL- SPIR-V compilers must be directed as to what SPIR-V Capabilities are legal at run-time and
give errors for GLSL feature use outside those capabilities. This is also true for implementation
dependent limits that can be error checked by the front-end against built-in constants present i
The glsL source: the front-end can be informed of such limits and report errors when they are
exceeded
SPIR-V features that are not controlled by a SPIR-V capability, but do have an equivalent GLSL
counterpart (stages, built-in functions, types, limits, etc )are only expected to work on OpenGL
drivers that support the GLSL counterpart
All references in this specification to the OpenGL Specification are to the Core profile of version 4.6,
unless a different profile is specified
1.1. Changes
1.1.1. Changes from Revision 6 of GLSL 4.6
Incorporated the GL_Khr_vulkan_glsl specification
Add note in the introduction about presence in drivers of sPir-v features, as they relate to glsl
features
Clarify it is same location that triggers default-uniform block matching rules. See Uniform
Variable Layout qualifiers
1.1.2. Changes from Revision 5 of GLSL 4.6
Private glSL issue #34: Clarify/consolidate implicit conversion rules from int -uint to be the
same as explicit construction.
Private GLSL issue #24: Clarify that barriero by itself is enough to synchronize both control
flow and memory accesses to shared variables and tessellation control output variables. For
other memory accesses an additional memory barrier is still required
Normatively reference IEEE-754 for definitions of floating-point formats
Private GLSL issue 36: refract function on double types requires eta argument to have type
double
Clarify restrictions on input variables in tessellation and geometry stages
Private GLSL issue 15: Clarify the ordering of bindings for arrays of arrays.
Private GLSL issue 14: Uniform variables need only match at link time if they are statically used
For precise computations, the controlling expressions for control flow and ternary operators
? are not included
1.1.3. Changes from Revision 4 of GLSL 4.6
Private bug 13012: Clarified that builtin uniform variables might only be available in the
fragment stage.
Private bug 13837: Ternary and sequence operators may operate on void types
Clarified that errors arising from preprocessing must be returned at compile time
Clarified that access to any part of a variable constitutes a static use
Private GLSL issue 19: A statement is required following any label at the end of a switch
Private GLSL issue 26: noise is not valid when compiling for SPIR-V
Private glsl issue 20: length expressions returning a constant value may not contain side
effects
Public OpenGL-API issue 7: Variables can be declared as both readonly and writeonly
Private GlSL issue 16: Use of constant expressions within #line directives is undefined.
Corrected return type of imageAtomicExchange on float images
Private glsL issue 32: Remove length method contradiction: Non runtime-sized arrays only
support length on explicitly sized arrays
Private Glsl issue 21: Clarified the l-value restriction on interpolateAt
Private Open GL-APi issue 53: Clarified bit-width requirements for location aliasing
Public glsl issue 15: gl in can be redeclared using unsized-array syntax
Clarification of the formats needed for depth component and stencil component for
depth/stencil textures
Added image formats to the layout-qualifier table in the Layout Qualifiers section
1.1.4. Changes from Revision 3 of GLSL 4.6
Private GLSL issue 13: Fix misspelling of allInvocationsEqualo.(The one in the table was
incorrectly listed as anylnvocationsEqualO, other spellings were correct.
1.1.5. Summary of Changes from Revision 7 of GLsL Version 4.50
Incorporated the gl arb shader atomic counter ops extension
Incorporated the GL_ArB__shader_draw_parameters extension
Incorporated the GL_ ArB_shader_ group_vote extension
Incorporated the GL_arB__gl_spirv extension
Private Bug 16070: Allow extra semi-colons at global scope
Private GLSL Issue 5: Be explicit that"fail to link "is really " compile-time or link-time error", for
some forms of error
Private GLSL Issue 7: Change gl MaxComputeUniformComponents to 1024
Private OpenGL api Issue 35: Require location on transparent individual uniform variables for
SPIR-V
Private GLSL Issue 8: Be more clear an interpolateAtO interpolant can be a structure member.
Private GLSL Issue 9: Specify how xfb_ buffer interacts with a block array: the capturing buffer
increments for each block array element.
1.2. Overview
This document describes The OpengL Shading language, version 4.60
Independent compilation units written in this language are called shaders. A program is a set of
shaders that are compiled and linked together, completely creating one or more of the
programmable stages of the API pipeline. All the shaders for a single programmable stage must be
within the same program. A complete set of programmable stages can be put into a single program
or the stages can be partitioned across multiple programs. The aim of this document is to
Thoroughly specify the programming language. The normative references will specify the API entry
points used to manipulate and communicate with programs and shaders
1.3. Error Handling
Compilers, in general, accept programs that are ill-formed, due to the impossibility of detecting all
ill-formed programs. Portability is only ensured for well-formed programs, which this specification
describes Compilers are encouraged to detect ill-formed programs and issue diagnostic messages,
but are not required to do so for all cases. Compile-time errors must be returned for lexically or
grammatically incorrect shaders. Other errors are reported at compile time or link time as
ndicated Code that is"dead"must still be error checked For example:
if(false
/ changing false to true cannot uncover additional errors
statement// statement must be error checked regardle
1.4. Typographical Conventions
Italic, bold, and font choices have been used in this specification primarily to improve readability
Code fragments use a fixed width font. Identifiers embedded in text are italicized. Keywords
embedded in text are bold Operators are called by their name, followed by their symbol in bold in
parentheses. The clarifying grammar fragments in the text use bold for literals and italics for non-
terminals. The official grammar in "Shading Language Grammar" uses all capitals for terminals
and lower case for non-terminals
1.5. Deprecation
The OpengL shading language has deprecated some features. These are clearly called out in this
specification as"deprecated". They are still present in this version of the language, but are targeted
for potential removal in a future version of the shading language. The OpenGL API has a forward
compatibility mode that will disallow use of deprecated features. If compiling in a mode where use
of deprecated features is disallowed, their use causes compile-time or link-time errors. See the
OpenGL Specification for details on what causes deprecated language features to be accepted or to
return an error
Chapter 2. Overview of Shading
The OpenGl Shading Language is actually several closely related languages. These languages are
used to create shaders for each of the programmable processors contained in the API's processing
pipeline. Currently, these processors are the vertex, tessellation control, tessellation evaluation,
geometry, fragment, and compute processors
Unless otherwise noted in this paper, a language feature applies to all languages, and common
usage will refer to these languages as a single language. The specific languages will be referred to
by the name of the processor they target: vertex, tessellation control, tessellation evaluation,
geometry, fragment, or compute
Most API state is not tracked or made available to shaders. Typically, user-defined variables will be
used for communicating between different stages of the API pipeline. However, a small amount of
state is still tracked and automatically made available to shaders, and there are a few built-in
variables for interfaces between different stages of the api pipeline
2.1 Vertex processor
The vertex processor is a programmable unit that operates on incoming vertices and their
associated data. Compilation units written in the OpenGL Shading language to run on this
processor are called vertex shaders. When a set of vertex shaders are successfully compiled and
linked, they result in a vertex shader executable that runs on the vertex processor
The vertex processor operates on one vertex at a time. It does not replace graphics operations that
require knowledge of several vertices at a time
2.2. Tessellation control processor
The tessellation control processor is a programmable unit that operates on a patch of incoming
vertices and their associated data, emitting a new output patch. Compilation units written in the
OpengL Shading language to run on this processor are called tessellation control shaders. When a
set of tessellation control shaders are successfully compiled and linked, they result in a tessellation
control shader executable that runs on the tessellation control processor
The tessellation control shader is invoked for each vertex of the output patch. Each invocation can
read the attributes of any vertex in the input or output patches, but can only write per-vertex
attributes for the corresponding output patch vertex. The shader invocations collectively produce a
set of per-patch attributes for the output patch
After all tessellation control shader invocations have completed, the output vertices and per-patch
attributes are assembled to form a patch to be used by subsequent pipeline stages
Tessellation control shader invocations run mostly independently, with undefined relative
execution order. However the built-in function harrier can be used to control execution order b
synchronizing invocations, effectively dividing tessellation control shader execution into a set of
phases. Tessellation control shaders will get undefined results if one invocation reads from a per
vertex or per-patch attribute written by another invocation at any point during the same phase, or
(系统自动生成,下载前可以参看下载内容)
下载文件列表
相关说明
- 本站资源为会员上传分享交流与学习,如有侵犯您的权益,请联系我们删除.
- 本站是交换下载平台，提供交流渠道，下载内容来自于网络，除下载问题外，其它问题请自行百度。
- 本站已设置防盗链，请勿用迅雷、QQ旋风等多线程下载软件下载资源，下载后用WinRAR最新版进行解压.
- 如果您发现内容无法下载，请稍后再次尝试；或者到消费记录里找到下载记录反馈给我们.
- 下载后发现下载的内容跟说明不相乎，请到消费记录里找到下载记录反馈给我们，经确认后退回积分.
- 如下载前有疑问，可以通过点击"提供者"的名字，查看对方的联系方式，联系对方咨询.
