• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    EXT_shader_image_load_formatted
4
5Name Strings
6
7    GL_EXT_shader_image_load_formatted
8
9Contact
10
11    Jeff Bolz, NVIDIA Corporation (jbolz 'at' nvidia.com)
12    Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)
13
14Contributors
15
16Status
17
18    Complete.
19
20Version
21
22    Last Modified Date:         March 11, 2014
23    Revision:                   1
24
25Number
26
27    OpenGL Extension #449
28
29Dependencies
30
31    This extension is written against the OpenGL 4.3 specification
32    (Compatibility Profile).
33
34    This extension is written against version 4.30 of the OpenGL
35    Shading Language Specification.
36
37    This extension interacts with GL_NV_bindless_texture.
38
39    This extension interacts with GL_EXT_shader_image_load_store and
40    NV_gpu_program5.
41
42Overview
43
44    ARB_shader_image_load_store (and OpenGL 4.2) added support for
45    random access load and store from/to texture images, but due to
46    hardware limitations, loads were required to declare the image
47    format in the shader source. This extension relaxes that
48    requirement, and the return values from imageLoad can be format-
49    converted based on the format of the image binding.
50
51New Procedures and Functions
52
53    None.
54
55New Tokens
56
57    None.
58
59Additions to Chapter 8 of the OpenGL 4.3 (Compatibility Profile) Specification
60(Rasterization)
61
62    Modify Section 8.25 Texture Image Loads and Stores, p. 284
63
64    (modify the bullet describing the format layout mismatch)
65
66    - the format layout qualifier for an image variable used for an image load
67      (if specified) or atomic operation does not match the format of the image
68      unit, according to table 8.33; or
69
70    (modify the first paragraph on p. 285)
71
72    Image variables used for shader loads, stores, and atomics may be declared
73    with a format layout qualifier. If the format layout qualifier is present,
74    then the format must match the format of the associated image unit, as
75    enumerated in table 8.33, otherwise the access is considered to involve a
76    format mismatch, as described above. Image variables used for atomics must
77    be declared with a format layout qualifier. Image variables used only for
78    loads and stores may be declared without a format layout qualifier, in which
79    case the format of the image is inferred from the associated image unit.
80
81
82New Implementation Dependent State
83
84    None.
85
86New State
87
88    None.
89
90Additions to the AGL/GLX/WGL Specifications
91
92    None.
93
94GLX Protocol
95
96    None.
97
98Modifications to the OpenGL Shading Language Specification, Version 4.30
99
100
101    Including the following line in a shader can be used to control the
102    language features described in this extension:
103
104      #extension GL_EXT_shader_image_load_formatted : <behavior>
105
106    where <behavior> is as specified in section 3.3.
107
108    New preprocessor #defines are added to the OpenGL Shading Language:
109
110      #define GL_EXT_shader_image_load_formatted    1
111
112
113    Modify Section 4.4.6.2 Format Layout Qualifiers (p. 71)
114
115    (modify the second paragraph on p.71)
116
117    Any image variable used for image atomic operations must specify a format
118    layout qualifier; it is a compile-time error to pass an image uniform
119    variable or function parameter declared without a format layout qualifier
120    to an image atomic function.
121
122    Delete the last paragraph on p.71: (Uniforms not qualified with <writeonly>
123    must have a format layout qualifier. ...)
124
125
126Errors
127
128
129
130Dependencies on NV_bindless_texture
131
132    When an image variable uses a bindless image handle, the format of the
133    image is inferred from the handle rather than "from the associated image
134    unit".
135
136Dependencies on EXT_shader_image_load_store and NV_gpu_program5
137
138    Modify Section 2.X.4, Program Execution Environment
139
140      Instr-      Modifiers
141      uction  V  F I C S H D  Out Inputs    Description
142      ------- -- - - - - - -  --- --------  --------------------------------
143      LOADIM  50 X X X X - F  v   vs,i      image load
144
145    (Add to "Section 2.X.6, Program Options" of the NV_gpu_program4 extension,
146    as extended by NV_gpu_program5:)
147
148      + Formatted Image Loads (EXT_shader_image_load_formatted)
149
150      If a program specifies the "EXT_shader_image_load_formatted" option, it
151      may use the "F", "U", or "S" data types with the "LOADIM" opcodes to
152      perform formatted image load operations.
153
154    Modify Section 2.X.8.Z, (LOADIM:  Image Load)
155
156    LOADIM supports an optional base data type (formatted) or storage modifier
157    (unformatted).  Formatted image loads operate as described in Section 8.25.
158    Unformatted image loads are treated as invalid unless the storage modifier
159    matches the image unit format, as described in Table X.3.  The base data
160    type of the result vector is derived from the storage modifier. The single
161    operand is always interpreted as a signed integer vector.
162
163          Class      Supported Modifers
164          -------    -------------------
165          4x32       F32X4, S32X4, U32X4
166          2x32       F32X2, S32X2, U32X2
167          1x32       F32,   S32,   U32
168          1x16              S16,   U16
169          1x8               S8,    U8
170
171      Table X.3, Supported Storage Modifiers.  Unformatted image operations
172      are considered invalid unless the storage modifier is compatible with
173      the "Class" entry for the image unit format, as described in Table
174      8.33.
175
176
177Issues
178
179
180Revision History
181
182    Rev.    Date    Author    Changes
183    ----  --------  --------  -----------------------------------------------
184     1    01/28/14  jbolz     Internal revisions.
185