Name ARB_shader_image_load_store Name Strings ARB_shader_image_load_store Contact Jeff Bolz, NVIDIA Corporation (jbolz 'at' nvidia.com) Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) Contributors Barthold Lichtenbelt, NVIDIA Bill Licea-Kane, AMD Eric Werness, NVIDIA Graham Sellers, AMD Greg Roth, NVIDIA Nick Haemel, AMD Pierre Boudier, AMD Piers Daniell, NVIDIA Notice Copyright (c) 2011-2013 The Khronos Group Inc. Copyright terms at http://www.khronos.org/registry/speccopyright.html Status Complete. Approved by the ARB on 2011/06/20. Approved by the Khronos Promoters on 2011/07/29. Version Last Modified Date: October 16, 2013 Revision: 33 Number ARB Extension #115 Dependencies This extension is written against the OpenGL 3.2 specification (Compatibility Profile). This extension is written against version 1.50 (revision 09) of the OpenGL Shading Language Specification. OpenGL 3.0 and GLSL 1.30 are required. This extension interacts trivially with OpenGL 3.2 (Core Profile). This extension interacts trivially with OpenGL 3.1, ARB_uniform_buffer_object, and EXT_bindable_uniform. This extension interacts trivially with ARB_draw_indirect. This extension interacts trivially with NV_vertex_buffer_unified_memory. This extension interacts with NV_parameter_buffer_object. This extension interacts trivially with OpenGL 3.2 and ARB_texture_multisample. This extension interacts trivially with OpenGL 4.0 and ARB_sample_shading. This extension interacts trivially with OpenGL 4.0 and ARB_texture_cube_map_array. This extension interacts trivially with OpenGL 3.3 and ARB_texture_rgb10_a2ui. This extension interacts trivially with NV_shader_buffer_load. This extension interacts trivially with OpenGL 4.0, ARB_gpu_shader5, and NV_gpu_shader5. This extension interacts trivially with OpenGL 4.0 and ARB_tessellation_shader. This extension interacts trivially with EXT_depth_bounds_test. This extension interacts with ARB_separate_shader_objects. This extension interacts with EXT_shader_image_load_store. Overview This extension provides GLSL built-in functions allowing shaders to load from, store to, and perform atomic read-modify-write operations to a single level of a texture object from any shader stage. These built-in functions are named imageLoad(), imageStore(), and imageAtomic*(), respectively, and accept integer texel coordinates to identify the texel accessed. The extension adds the notion of "image units" to the OpenGL API, to which texture levels are bound for access by the GLSL built-in functions. To allow shaders to specify the image unit to access, GLSL provides a new set of data types ("image*") similar to samplers. Each image variable is assigned an integer value to identify an image unit to access, which is specified using Uniform*() APIs in a manner similar to samplers. This extension also provides the capability to explicitly enable "early" per-fragment tests, where operations like depth and stencil testing are performed prior to fragment shader execution. In unextended OpenGL, fragment shaders never have any side effects and implementations can sometimes perform per-fragment tests and discard some fragments prior to executing the fragment shader. Since this extension allows fragment shaders to write to texture and buffer object memory using the built-in image functions, such optimizations could lead to non-deterministic results. To avoid this, implementations supporting this extension may not perform such optimizations on shaders having such side effects. However, enabling early per-fragment tests guarantees that such tests will be performed prior to fragment shader execution, and ensures that image stores and atomics will not be performed by fragment shader invocations where these per-fragment tests fail. Finally, this extension provides both a GLSL built-in function and an OpenGL API function allowing applications some control over the ordering of image loads, stores, and atomics relative to other OpenGL pipeline operations accessing the same memory. Because the extension provides the ability to perform random accesses to texture or buffer object memory, such accesses are not easily tracked by the OpenGL driver. To avoid the need for heavy-handed synchronization at the driver level, this extension requires manual synchronization. The MemoryBarrier() OpenGL API function allows applications to specify a bitfield indicating the set of OpenGL API operations to synchronize relative to shader memory access. The memoryBarrier() GLSL built-in function provides a synchronization point within a given shader invocation to ensure that all memory accesses performed prior to the synchronization point complete prior to any started after the synchronization point. New Procedures and Functions void BindImageTexture(uint unit, uint texture, int level, boolean layered, int layer, enum access, enum format); void MemoryBarrier(bitfield barriers); New Tokens Accepted by the parameter of GetBooleanv, GetIntegerv, GetFloatv, GetDoublev, and GetInteger64v: MAX_IMAGE_UNITS 0x8F38 MAX_COMBINED_IMAGE_UNITS_AND_FRAGMENT_OUTPUTS 0x8F39 MAX_IMAGE_SAMPLES 0x906D MAX_VERTEX_IMAGE_UNIFORMS 0x90CA MAX_TESS_CONTROL_IMAGE_UNIFORMS 0x90CB MAX_TESS_EVALUATION_IMAGE_UNIFORMS 0x90CC MAX_GEOMETRY_IMAGE_UNIFORMS 0x90CD MAX_FRAGMENT_IMAGE_UNIFORMS 0x90CE MAX_COMBINED_IMAGE_UNIFORMS 0x90CF Accepted by the parameter of GetIntegeri_v and GetBooleani_v: IMAGE_BINDING_NAME 0x8F3A IMAGE_BINDING_LEVEL 0x8F3B IMAGE_BINDING_LAYERED 0x8F3C IMAGE_BINDING_LAYER 0x8F3D IMAGE_BINDING_ACCESS 0x8F3E IMAGE_BINDING_FORMAT 0x906E Accepted by the parameter of MemoryBarrier: VERTEX_ATTRIB_ARRAY_BARRIER_BIT 0x00000001 ELEMENT_ARRAY_BARRIER_BIT 0x00000002 UNIFORM_BARRIER_BIT 0x00000004 TEXTURE_FETCH_BARRIER_BIT 0x00000008 SHADER_IMAGE_ACCESS_BARRIER_BIT 0x00000020 COMMAND_BARRIER_BIT 0x00000040 PIXEL_BUFFER_BARRIER_BIT 0x00000080 TEXTURE_UPDATE_BARRIER_BIT 0x00000100 BUFFER_UPDATE_BARRIER_BIT 0x00000200 FRAMEBUFFER_BARRIER_BIT 0x00000400 TRANSFORM_FEEDBACK_BARRIER_BIT 0x00000800 ATOMIC_COUNTER_BARRIER_BIT 0x00001000 ALL_BARRIER_BITS 0xFFFFFFFF Returned by the parameter of GetActiveUniform: IMAGE_1D 0x904C IMAGE_2D 0x904D IMAGE_3D 0x904E IMAGE_2D_RECT 0x904F IMAGE_CUBE 0x9050 IMAGE_BUFFER 0x9051 IMAGE_1D_ARRAY 0x9052 IMAGE_2D_ARRAY 0x9053 IMAGE_CUBE_MAP_ARRAY 0x9054 IMAGE_2D_MULTISAMPLE 0x9055 IMAGE_2D_MULTISAMPLE_ARRAY 0x9056 INT_IMAGE_1D 0x9057 INT_IMAGE_2D 0x9058 INT_IMAGE_3D 0x9059 INT_IMAGE_2D_RECT 0x905A INT_IMAGE_CUBE 0x905B INT_IMAGE_BUFFER 0x905C INT_IMAGE_1D_ARRAY 0x905D INT_IMAGE_2D_ARRAY 0x905E INT_IMAGE_CUBE_MAP_ARRAY 0x905F INT_IMAGE_2D_MULTISAMPLE 0x9060 INT_IMAGE_2D_MULTISAMPLE_ARRAY 0x9061 UNSIGNED_INT_IMAGE_1D 0x9062 UNSIGNED_INT_IMAGE_2D 0x9063 UNSIGNED_INT_IMAGE_3D 0x9064 UNSIGNED_INT_IMAGE_2D_RECT 0x9065 UNSIGNED_INT_IMAGE_CUBE 0x9066 UNSIGNED_INT_IMAGE_BUFFER 0x9067 UNSIGNED_INT_IMAGE_1D_ARRAY 0x9068 UNSIGNED_INT_IMAGE_2D_ARRAY 0x9069 UNSIGNED_INT_IMAGE_CUBE_MAP_ARRAY 0x906A UNSIGNED_INT_IMAGE_2D_MULTISAMPLE 0x906B UNSIGNED_INT_IMAGE_2D_MULTISAMPLE_ARRAY 0x906C Accepted by the parameter of GetTexParameteriv, GetTexParameterfv, GetTexParameterIiv, and GetTexParameterIuiv: IMAGE_FORMAT_COMPATIBILITY_TYPE 0x90C7 Returned in the parameter of GetTexParameteriv, GetTexParameterfv, GetTexParameterIiv, and GetTexParameterIuiv when is IMAGE_FORMAT_COMPATIBILITY_TYPE: IMAGE_FORMAT_COMPATIBILITY_BY_SIZE 0x90C8 IMAGE_FORMAT_COMPATIBILITY_BY_CLASS 0x90C9 Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification (Rasterization) Modify Section 2.14.4, Uniform Variables, p. 89 (modify second paragraph, p. 90) Sets of uniforms, except for samplers and images, can be grouped into uniform blocks. ... (Add new types to table 2.13, pp. 96-98) Type Name Keyword ------------------------------ ------------------------- IMAGE_1D image1D IMAGE_2D image2D IMAGE_3D image3D IMAGE_2D_RECT image2DRect IMAGE_CUBE imageCube IMAGE_BUFFER imageBuffer IMAGE_1D_ARRAY image1DArray IMAGE_2D_ARRAY image2DArray IMAGE_CUBE_MAP_ARRAY imageCubeArray IMAGE_2D_MULTISAMPLE image2DMS IMAGE_2D_MULTISAMPLE_ARRAY image2DMSArray INT_IMAGE_1D iimage1D INT_IMAGE_2D iimage2D INT_IMAGE_3D iimage3D INT_IMAGE_2D_RECT iimage2DRect INT_IMAGE_CUBE iimageCube INT_IMAGE_BUFFER iimageBuffer INT_IMAGE_1D_ARRAY iimage1DArray INT_IMAGE_2D_ARRAY iimage2DArray INT_IMAGE_CUBE_MAP_ARRAY iimageCubeArray INT_IMAGE_2D_MULTISAMPLE iimage2DMS INT_IMAGE_2D_MULTISAMPLE_ARRAY iimage2DMSArray UNSIGNED_INT_IMAGE_1D uimage1D UNSIGNED_INT_IMAGE_2D uimage2D UNSIGNED_INT_IMAGE_3D uimage3D UNSIGNED_INT_IMAGE_2D_RECT uimage2DRect UNSIGNED_INT_IMAGE_CUBE uimageCube UNSIGNED_INT_IMAGE_BUFFER uimageBuffer UNSIGNED_INT_IMAGE_1D_ARRAY uimage1DArray UNSIGNED_INT_IMAGE_2D_ARRAY uimage2DArray UNSIGNED_INT_IMAGE_CUBE_MAP_ARRAY uimageCubeArray UNSIGNED_INT_IMAGE_2D_MULTISAMPLE uimage2DMS UNSIGNED_INT_IMAGE_2D_MULTISAMPLE_ARRAY uimage2DMSArray (Add a new subsection after Section 2.14.5, Samplers, p. 106) Section 2.14.X, Images Images are special uniforms used in the OpenGL Shading Language to identify a level of a texture to be read or written using image load, store, and atomic built-in functions in the manner described in Section 3.9.X. The value of an image uniform is an integer specifying the image unit accessed. Image units are numbered beginning at zero, and there is an implementation-dependent number of available image units (MAX_IMAGE_UNITS). The error INVALID_VALUE is generated if a Uniform1i{v} call is used to set an image uniform to a value less than zero or greater than or equal to MAX_IMAGE_UNITS. Note that image units used for image variables are independent of the texture image units used for sampler variables; the number of units provided by the implementation may differ. Textures are bound independently and separately to image and texture image units. The type of an image variable must match the texture target of the image currently bound to the image unit, otherwise the result of a load, store, or atomic operation is undefined (see Section 4.1.X of the OpenGL Shading Language specification for more detail). The location of an image variable needs to be queried with GetUniformLocation, just like any uniform variable. Image values need to be set by calling Uniform1i{v}. Loading image variables with any of the other Uniform entry point is not allowed and will result in an INVALID_OPERATION error. Unlike samplers, there is no limit on the number of active image variables that may be used by a program or by any particular shader. However, given that there is an implementation-dependent limit on the number of unique image units, the actual number of images that may be used by all shaders in a program is limited. Modify Section 2.14.7, Shader Execution, p. 109 (Add a new unnumbered subsection before "Shader Inputs", p. 113) Image Access Shaders have the ability read and write to textures using image uniforms. The maximum number of image uniforms available to individual shader stages are the values of the implementation dependent constants * MAX_VERTEX_IMAGE_UNIFORMS (vertex shaders), * MAX_TESS_CONTROL_IMAGE_UNIFORMS (tessellation control shaders), * MAX_TESS_EVALUATION_IMAGE_UNIFORMS (tessellation evaluation shaders), * MAX_GEOMETRY_IMAGE_UNIFORMS (geometry shaders), and * MAX_FRAGMENT_IMAGE_UNIFORMS (fragment shaders). All active shaders combined cannot use more than the value of MAX_COMBINED_IMAGE_UNIFORMS atomic counters. If more than one shader stage accesses the same image uniform, each such access counts separately against the MAX_COMBINED_IMAGE_UNIFORMS limit. (Add a new numbered subsection after Section 2.14.7, Shader Execution, p. 109) Section 2.14.X, Shader Memory Access Shaders may perform random-access reads and writes to texture or buffer object memory using built-in image load, store, and atomic functions, as described in the OpenGL Shading Language Specification. The ability to perform such random-access reads and writes in systems that may be highly pipelined results in ordering and synchronization issues discussed in the sections below. Shader Memory Access Ordering The order in which texture or buffer object memory is read or written by shaders is largely undefined. For some shader types (vertex, tessellation evaluation, and in some cases, fragment), even the number of shader invocations that might perform loads and stores is undefined. In particular, the following rules apply: * While a vertex or tessellation evaluation shader will be executed at least once for each unique vertex specified by the application (vertex shaders) or generated by the tessellation primitive generator (tessellation evaluation shaders), it may be executed more than once for implementation-dependent reasons. Additionally, if the same vertex is specified multiple times in a collection of primitives (e.g., repeating an index in DrawElements), the vertex shader might be run only once. * For each fragment generated by the GL, the number of fragment shader invocations depends on a number of factors. If the fragment fails the pixel ownership test (Section 4.1.1), the fragment shader may not be executed. Otherwise, if the framebuffer has no multisample buffer (SAMPLE_BUFFERS is zero), the fragment shader will be invoked exactly once. If the fragment shader specifies per-sample shading, the fragment shader will be run once per covered sample. Otherwise, the number of fragment shader invocations is undefined, but must be in the range [1,], where is the number of samples covered by the fragment. * If a fragment shader is invoked to process fragments or samples not covered by a primitive being rasterized to facilitate the approximation of derivatives for texture lookups, stores and atomics have no effect. * The relative order of invocations of the same shader type are undefined. A store issued by a shader when working on primitive B might complete prior to a store for primitive A, even if primitive A is specified prior to primitive B. This applies even to fragment shaders; while fragment shader outputs are written to the framebuffer in primitive order, stores executed by fragment shader invocations are not. * The relative order of invocations of different shader types is largely undefined. However, when executing a shader whose inputs are generated from a previous programmable stage, the shader invocations from the previous stage are guaranteed to have executed far enough to generate final values for all next-stage inputs. That implies shader completion for all stages except geometry; geometry shaders are guaranteed only to have executed far enough to emit all needed vertices. The above limitations on shader invocation order also make some forms of synchronization between shader invocations within a single set of primitives unimplementable. For example, having one invocation poll memory written by another invocation assumes that the other invocation has been launched and can complete its writes. The only case where such a guarantee is made is when the inputs of one shader invocation are generated from the outputs of a shader invocation in a previous stage. Stores issued to different memory locations within a single shader invocation may not be visible to other invocations in the order they were performed. The built-in function memoryBarrier() may be used to provide stronger ordering of reads and writes performed by a single invocation. Calling memoryBarrier() guarantees that any memory transactions issued by the shader invocation prior to the call complete prior to the memory transactions issued after the call. Memory barriers may be needed for algorithms that require multiple invocations to access the same memory and require the operations need to be performed in a partially-defined relative order. For example, if one shader invocation does a series of writes, followed by a memoryBarrier() call, followed by another write, then another invocation that sees the results of the final write will also see the previous writes. Without the memory barrier, the final write may be visible before the previous writes. The atomic memory transaction built-in functions may be used to read and write a given memory address atomically. While atomic built-in functions issued by multiple shader invocations are executed in undefined order relative to each other, these functions perform both a read and a write of a memory address and guarantee that no other memory transaction will write to the underlying memory between the read and write. Atomics allow shaders to use shared global addresses for mutual exclusion or as counters, among other uses. Shader Memory Access Synchronization Data written to textures or buffer objects by a shader invocation may eventually be read by other shader invocations, sourced by other fixed pipeline stages, or read back by the application. When applications write to buffer objects or textures using API commands such as TexSubImage* or BufferSubData, the GL implementation knows when and where writes occur and can perform implicit synchronization to ensure that operations requested before the update see the original data and that subsequent operations see the modified data. Without logic to track the target address of each shader instruction performing a store, automatic synchronization of stores performed by a shader invocation would require the GL implementation to make worst-case assumptions at significant performance cost. To permit cases where textures or buffers may be read or written in different pipeline stages without the overhead of automatic synchronization, buffer object and texture stores performed by shaders are not automatically synchronized with other GL operations using the same memory. Explicit synchronization is required to ensure that the effects of buffer and texture data stores performed by shaders will be visible to subsequent operations using the same objects and will not overwrite data still to be read by previously requested operations. Without manual synchronization, shader stores for a "new" primitive may complete before processing of an "old" primitive completes. Additionally, stores for an "old" primitive might not be completed before processing of a "new" primitive starts. The command void MemoryBarrier(bitfield barriers) defines a barrier ordering the memory transactions issued prior to the command relative to those issued after the barrier. For the purposes of this ordering, memory transactions performed by shaders are considered to be issued by the rendering command that triggered the execution of the shader. is a bitfield indicating the set of operations that are synchronized with shader stores; the bits used in are as follows: - VERTEX_ATTRIB_ARRAY_BARRIER_BIT: If set, vertex data sourced from buffer objects after the barrier will reflect data written by shaders prior to the barrier. The set of buffer objects affected by this bit is derived from the buffer object bindings or GPU addresses used for generic vertex attributes (VERTEX_ATTRIB_ARRAY_BUFFER bindings, VERTEX_ATTRIB_ARRAY_ADDRESS from NV_vertex_buffer_unified_memory), as well as those for arrays of named vertex attributes (e.g., vertex, color, normal). - ELEMENT_ARRAY_BARRIER_BIT: If set, vertex array indices sourced from buffer objects after the barrier will reflect data written by shaders prior to the barrier. The buffer objects affected by this bit are derived from the ELEMENT_ARRAY_BUFFER binding and the NV_vertex_buffer_unified_memory ELEMENT_ARRAY_ADDRESS address. - UNIFORM_BARRIER_BIT: Shader uniforms and assembly program parameters sourced from buffer objects after the barrier will reflect data written by shaders prior to the barrier. - TEXTURE_FETCH_BARRIER_BIT: Texture fetches from shaders, including fetches from buffer object memory via buffer textures, after the barrier will reflect data written by shaders prior to the barrier. - SHADER_IMAGE_ACCESS_BARRIER_BIT: Memory accesses using shader image load, store, and atomic built-in functions issued after the barrier will reflect data written by shaders prior to the barrier. Additionally, image stores and atomics issued after the barrier will not execute until all memory accesses (e.g., loads, stores, texture fetches, vertex fetches) initiated prior to the barrier complete. - COMMAND_BARRIER_BIT: Command data sourced from buffer objects by Draw*Indirect commands after the barrier will reflect data written by shaders prior to the barrier. The buffer objects affected by this bit are derived from the DRAW_INDIRECT_BUFFER binding and the GPU address DRAW_INDIRECT_ADDRESS_NV. - PIXEL_BUFFER_BARRIER_BIT: Reads/writes of buffer objects via the PACK/UNPACK_BUFFER bindings (ReadPixels, TexSubImage, etc.) after the barrier will reflect data written by shaders prior to the barrier. Additionally, buffer object writes issued after the barrier will wait on the completion of all shader writes initiated prior to the barrier. - TEXTURE_UPDATE_BARRIER_BIT: Writes to a texture via Tex(Sub)Image*, CopyTex(Sub)Image*, CompressedTex(Sub)Image*, and reads via GetTexImage after the barrier will reflect data written by shaders prior to the barrier. Additionally, texture writes from these commands issued after the barrier will not execute until all shader writes initiated prior to the barrier complete. - BUFFER_UPDATE_BARRIER_BIT: Reads/writes via Buffer(Sub)Data, CopyBufferSubData, ProgramBufferParametersNV, and GetBufferSubData, or to buffer object memory mapped by MapBuffer(Range) after the barrier will reflect data written by shaders prior to the barrier. Additionally, writes via these commands issued after the barrier will wait on the completion of any shader writes to the same memory initiated prior to the barrier. - FRAMEBUFFER_BARRIER_BIT: Reads and writes via framebuffer object attachments after the barrier will reflect data written by shaders prior to the barrier. Additionally, framebuffer writes issued after the barrier will wait on the completion of all shader writes issued prior to the barrier. - TRANSFORM_FEEDBACK_BARRIER_BIT: Writes via transform feedback bindings after the barrier will reflect data written by shaders prior to the barrier. Additionally, transform feedback writes issued after the barrier will wait on the completion of all shader writes issued prior to the barrier. - ATOMIC_COUNTER_BARRIER_BIT: Accesses to atomic counters after the barrier will reflect writes prior to the barrier. If is ALL_BARRIER_BITS, shader memory accesses will be synchronized relative to all the operations described above. Implementations may cache buffer object and texture image memory that could be written by shaders in multiple caches; for example, there may be separate caches for texture, vertex fetching, and one or more caches for shader memory accesses. Implementations are not required to keep these caches coherent with shader memory writes. Stores issued by one invocation may not be immediately observable by other pipeline stages or other shader invocations because the value stored may remain in a cache local to the processor executing the store, or because data overwritten by the store is still in a cache elsewhere in the system. When MemoryBarrier is called, the GL flushes and/or invalidates any caches relevant to the operations specified by the parameter to ensure consistent ordering of operations across the barrier. To allow for independent shader invocations to communicate by reads and writes to a common memory address, image variables in the OpenGL Shading Language may be declared as "coherent". Buffer object or texture image memory accessed through such variables may be cached only if caches are automatically updated due to stores issued by any other shader invocation. If the same address is accessed using both coherent and non-coherent variables, the accesses using variables declared as coherent will observe the results stored using coherent variables in other invocations. Using variables declared as "coherent" guarantees only that the results of stores will be immediately visible to shader invocations using similarly-declared variables; calling MemoryBarrier is required to ensure that the stores are visible to other operations. The following guidelines may be helpful in choosing when to use coherent memory accesses and when to use barriers. - Data that are read-only or constant may be accessed without using coherent variables or calling MemoryBarrier(). Updates to the read-only data via API calls such as BufferSubData will invalidate shader caches implicitly as required. - Data that are shared between shader invocations at a fine granularity (e.g., written by one invocation, consumed by another invocation) should use coherent variables to read and write the shared data. - Data written by one shader invocation and consumed by other shader invocations launched as a result of its execution ("dependent invocations") should use coherent variables in the producing shader invocation and call memoryBarrier() after the last write. The consuming shader invocation should also use coherent variables. - Data written to image variables in one rendering pass and read by the shader in a later pass need not use coherent variables or memoryBarrier(). Calling MemoryBarrier() with the SHADER_IMAGE_ACCESS_BARRIER_BIT set in between passes is necessary. - Data written by the shader in one rendering pass and read by another mechanism (e.g., vertex or index buffer pulling) in a later pass need not use coherent variables or memoryBarrier(). Calling MemoryBarrier() with the appropriate bits set in between passes is necessary. Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification (Rasterization) (insert new section immediately before Section 3.8, Texturing, p. 210) Section 3.X, Early Per-Fragment Tests Once fragments are produced by rasterization (sections 3.4 through 3.8), a number of per-fragment operations may be performed prior to fragment shader execution. If a fragment is discarded during any of these operations, it will not be processed by any subsequent stage, including fragment shader execution. Up to six operations are performed on each fragment, in the following order: * the pixel ownership test, described in section 4.1.1; * the scissor test, described in section 4.1.2; * the depth bounds test, described in section 4.1.X (of the EXT_depth_bounds_test specification); * the stencil test, described in section 4.1.5; * the depth buffer test, described in section 4.1.6; and * occlusion query sample counting, described in section 4.1.7. The pixel ownership and scissor tests are always performed. The other operations are performed if and only if early fragment tests are enabled in the active fragment shader (section 3.12.2). When early per-fragment operations are enabled, the depth bounds test, stencil test, depth buffer test, and occlusion query sample counting operations are performed prior to fragment shader execution, and the stencil buffer, depth buffer, and occlusion query sample counts will be updated accordingly. When early per-fragment operations are enabled, these operations will not be performed again after fragment shader execution. When there is no active program, the active program has no fragment shader, or the active program was linked with early fragment tests disabled, these operations are performed only after fragment program execution, in the order described in chapter 4. If early fragment tests are enabled, any depth value computed by the fragment shader has no effect. Additionally, the depth buffer, stencil buffer, and occlusion query sample counts may be updated even for fragments or samples that would be discarded after fragment shader execution due to per-fragment operations such as alpha-to-coverage or alpha tests. (Add new section after Section 3.9.19, Texture Application, p. 268) Section 3.9.X, Texture Image Loads and Stores The contents of a texture may be made available for shaders to read and write by binding the texture to one of a collection of image units. The GL implementation provides an array of image units numbered beginning with zero, with the total number of image units provided given by the implementation-dependent constant MAX_IMAGE_UNITS. Unlike texture image units, image units do not have a separate attachment for each texture target texture; each image unit may have only one texture bound at a time. A texture may be bound to an image unit for use by image loads and stores by calling: void BindImageTexture(uint unit, uint texture, int level, boolean layered, int layer, enum access, enum format); where identifies the image unit, is the name of the texture, and selects a single level of the texture. If is zero, any texture currently bound to image unit is unbound. If is greater than or equal to the value of MAX_IMAGE_UNITS, if or is less than zero, or if is not the name of an existing texture object, the error INVALID_VALUE is generated. If the texture identified by is a one-dimensional array, two-dimensional array, three-dimensional, cube map, cube map array, or two-dimensional multisample array texture, it is possible to bind either the entire texture level or a single layer or face of the texture level. If is TRUE, the entire level is bound. If is FALSE, only the single layer identified by will be bound. When is FALSE, the single bound layer is treated as a different texture target for image accesses: * one-dimensional array texture layers are treated as one-dimensional textures; * two-dimensional array, three-dimensional, cube map, cube map array texture layers are treated as two-dimensional textures; and * two-dimensional multisample array textures are treated as two-dimensional multisample textures. For cube map textures where is FALSE, the face is taken by mapping the layer number to a face according to table 4.13. For cube map array textures where is FALSE, the selected layer number is mapped to a texture layer and cube face using the following equations and mapping to a face according to table 4.13. layer = floor(layer_orig / 6) face = layer_orig - (layer * 6) If the texture identified by does not have multiple layers or faces, the entire texture level is bound, regardless of the values specified by and . specifies the format that the elements of the image will be treated as when doing formatted stores, as described later in this section. This is referred to as the "image unit format". This must be one of the formats listed in Table X.2; otherwise, the error INVALID_VALUE is generated. specifies whether the texture bound to the image will be treated as READ_ONLY, WRITE_ONLY, or READ_WRITE. If a shader reads from an image unit with a texture bound as WRITE_ONLY, or writes to an image unit with a texture bound as READ_ONLY, the results of that shader operation are undefined and may lead to application termination. If a texture object bound to one or more image units is deleted by DeleteTextures, it is detached from each such image unit, as though BindImageTexture were called with identifying the image unit and set to zero. When a shader accesses the texture bound to an image unit using a built-in image load, store, or atomic function, it identifies a single texel by providing a one-, two-, or three-dimensional coordinate. Multisample texture accesses also specify a sample number. A coordinate vector is mapped to an individual texel tau_i, tau_i_j, or tau_i_j_k according to the target of the texture bound to the image unit using Table X.1. As noted above, single-layer bindings of array or cube map textures are considered to use a texture target corresponding to the bound layer, rather than that of the full texture. face/ i j k layer -- -- -- ----- TEXTURE_1D x - - - TEXTURE_2D x y - - TEXTURE_3D x y z - TEXTURE_RECTANGLE x y - - TEXTURE_CUBE_MAP x y - z TEXTURE_BUFFER x - - - TEXTURE_1D_ARRAY x - - y TEXTURE_2D_ARRAY x y - z TEXTURE_CUBE_MAP_ARRAY x y - z TEXTURE_2D_MULTISAMPLE x y - - TEXTURE_2D_MULTISAMPLE_ARRAY x y - z Table X.1, Mapping of image load, store, and atomic texel coordinate components to texel numbers. If the texture target has layers or cube map faces, the layer or face number is taken from the argument of BindImageTexture if the texture is bound with set to FALSE, or from the coordinate identified by Table X.1 otherwise. For cube map and cube map array textures with set to TRUE, the coordinate is mapped to a layer and face in the same manner as the argument of BindImageTexture. If the individual texel identified for an image load, store, or atomic operation doesn't exist, the access is treated as invalid. Invalid image loads will return zero. Invalid image stores will have no effect. Invalid image atomics will not update any texture bound to the image unit and will return zero. An access is considered invalid if: * no texture is bound to the selected image unit; * the texture bound to the selected image unit is incomplete; * the texture level bound to the image unit is less than the base level or greater than the maximum level of the texture; * [[compatiblity profile only]] the texture bound to the image unit is bordered; * the internal format of the texture bound to the image unit is not found in Table X.2; * the internal format of the texture bound to the image unit is incompatible with the specified according to Table X.3; * the texture bound to the image unit has layers, and the selected layer or cube map face doesn't exist; * the selected texel tau_i, tau_i_j, or tau_i_j_k doesn't exist; * the image has more samples than the implementation-dependent value of MAX_IMAGE_SAMPLES. Additionally, there are a number of cases where image load, store, or atomic operations are considered to involve a format mismatch. In such cases, undefined values will be returned by image loads and atomic operations and undefined values will be written by stores and atomic operations. A format mismatch will occur if: * the type of image variable used to access the image unit does not match the target of a texture bound to the image unit with set to TRUE; * the type of image variable used to access the image unit does not match the target corresponding to a single layer of a multi-layer texture target bound to the image unit with set to FALSE; * the type of image variable used to access the image unit has a component data type (floating-point, signed integer, unsigned integer) incompatible with the format of the image unit; * the format layout qualifier for an image variable used for an image load or atomic operation does not match the format of the image unit, according to Table X.2; or * the image variable used for an image store has a format layout qualifier, and that qualifier does not match the format of the image unit, according to Table X.2. For textures with multiple samples per texel, the sample selected for an image load, store, or atomic is undefined if the coordinate is negative or greater than or equal to the number of samples in the texture. If a shader performs an image load, store, or atomic operation using an image variable declared as an array, and if the index used to select an individual element is negative or greater than or equal to the size of the array, the results of the operation are undefined but may not lead to termination. Accesses to textures bound to image units do format conversions based on the argument specified when the image is bound. Loads always return a value as a vec4, ivec4, or uvec4, and stores always take the source data as a vec4, ivec4, or uvec4. Data are converted to/from the specified format according to the process described for a TexImage2D or GetTexImage command with and as RGBA and FLOAT for vec4 data, with and as RGBA_INTEGER and INT for ivec4 data, or with and as RGBA_INTEGER and UNSIGNED_INT for uvec4 data. Unused components are filled in with (0,0,0,1) (where "1" is either a floating-point or integer value, depending on the format). Any image variable used for shader loads or atomic memory operations must be declared with a format layout qualifier matching the format of its associated image unit, as enumerated in Table X.2. Otherwise, the access is considered to involve a format mismatch, as described above. Image variables used exclusively for image stores need not include a format layout qualifier, but any declared qualifier must match the image unit format to avoid a format mismatch. Image Unit Format Format Qualifer ----------------- --------------- RGBA32F rgba32f RGBA16F rgba16f RG32F rg32f RG16F rg16f R11F_G11F_B10F r11f_g11f_b10f R32F r32f R16F r16f RGBA32UI rgba32ui RGBA16UI rgba16ui RGB10_A2UI rgb10_a2ui RGBA8UI rgba8ui RG32UI rg32ui RG16UI rg16ui RG8UI rg8ui R32UI r32ui R16UI r16ui R8UI r8ui RGBA32I rgba32i RGBA16I rgba16i RGBA8I rgba8i RG32I rg32i RG16I rg16i RG8I rg8i R32I r32i R16I r16i R8I r8i RGBA16 rgba16 RGB10_A2 rgb10_a2 RGBA8 rgba8 RG16 rg16 RG8 rg8 R16 r16 R8 r8 RGBA16_SNORM rgba16_snorm RGBA8_SNORM rgba8_snorm RG16_SNORM rg16_snorm RG8_SNORM rg8_snorm R16_SNORM r16_snorm R8_SNORM r8_snorm Table X.2, Supported image unit formats, with equivalent format layout qualifiers. When a texture is bound to an image unit, the parameter for the image unit need not exactly match the texture internal format as long as the formats are considered compatible. A pair of formats is considered to match in size if the corresponding entries in the "size" column of able X.3 are identical. A pair of formats is considered to match by class if the corresponding entries in the "class" column of Table X.3 are identical. For textures allocated by the GL, an image unit format is compatible with a texture internal format if they match by size. For textures allocated outside the GL, format compatibility is determined by matching by size or by class, in an implementation dependent manner. The matching criterion used for a given texture may be determined by calling GetTexParameter with set to IMAGE_FORMAT_COMPATIBILITY_TYPE, with return values of IMAGE_FORMAT_COMPATIBILITY_BY_SIZE and IMAGE_FORMAT_COMPATIBILITY_BY_CLASS, specifying matches by size and class, respectively. When the format associated with an image unit does not exactly match the internal format of the texture bound to the image unit, image loads, stores, and atomic operations re-interpret the memory holding the components of an accessed texel according to the format of the image unit. The re-interpretation for image loads and the read portion of image atomics is performed as though data were copied from the texel of the bound texture to a similar texel represented in the format of the image unit. Similarly, the re-interpretation for image stores and the write portion of image atomics is performed as though data were copied from a texel represented in the format of the image unit to the texel in the bound texture. In both cases, this copy operation would be performed by: * reading the texel from the source format to scratch memory according to the process described for GetTexImage (section 6.1.4), using default pixel storage modes and and parameters corresponding to the source format in Table X.3; and * writing the texel from scratch memory to the destination format according to the process described for TexSubImage3D (section 3.9.2), using default pixel storage modes and and parameters corresponding to the destination format in Table X.3. [[compatibility profile only: No pixel transfer operations are performed during this conversion.]] Image Format Size Class Pixel Format/Type -------------- ---- ----- ----------------------------------------- RGBA32F 128 4x32 RGBA, FLOAT RGBA16F 64 4x16 RGBA, HALF_FLOAT RG32F 64 2x32 RG, FLOAT RG16F 32 2x16 RG, HALF_FLOAT R11F_G11F_B10F 32 (a) RGB, UNSIGNED_INT_10F_11F_11F_REV R32F 32 1x32 RED, FLOAT R16F 16 1x16 RED, HALF_FLOAT RGBA32UI 128 4x32 RGBA_INTEGER, UNSIGNED_INT RGBA16UI 64 4x16 RGBA_INTEGER, UNSIGNED_SHORT RGB10_A2UI 32 (b) RGBA_INTEGER, UNSIGNED_INT_2_10_10_10_REV RGBA8UI 32 4x8 RGBA_INTEGER, UNSIGNED_BYTE RG32UI 64 2x32 RG_INTEGER, UNSIGNED_INT RG16UI 32 2x16 RG_INTEGER, UNSIGNED_SHORT RG8UI 16 2x8 RG_INTEGER, UNSIGNED_BYTE R32UI 32 1x32 RED_INTEGER, UNSIGNED_INT R16UI 16 1x16 RED_INTEGER, UNSIGNED_SHORT R8UI 8 1x8 RED_INTEGER, UNSIGNED_BYTE RGBA32I 128 4x32 RGBA_INTEGER, INT RGBA16I 64 4x16 RGBA_INTEGER, SHORT RGBA8I 32 4x8 RGBA_INTEGER, BYTE RG32I 64 2x32 RG_INTEGER, INT RG16I 32 2x16 RG_INTEGER, SHORT RG8I 16 2x8 RG_INTEGER, BYTE R32I 32 1x32 RED_INTEGER, INT R16I 16 1x16 RED_INTEGER, SHORT R8I 8 1x8 RED_INTEGER, BYTE RGBA16 64 4x16 RGBA, UNSIGNED_SHORT RGB10_A2 32 (b) RGBA, UNSIGNED_INT_2_10_10_10_REV RGBA8 32 4x8 RGBA, UNSIGNED_BYTE RG16 32 2x16 RG, UNSIGNED_SHORT RG8 16 2x8 RG, UNSIGNED_BYTE R16 16 1x16 RED, UNSIGNED_SHORT R8 8 1x8 RED, UNSIGNED_BYTE RGBA16_SNORM 64 4x16 RGBA, SHORT RGBA8_SNORM 32 4x8 RGBA, BYTE RG16_SNORM 32 2x16 RG, SHORT RG8_SNORM 16 2x8 RG, BYTE R16_SNORM 16 1x16 RED, SHORT R8_SNORM 8 1x8 RED, BYTE Table X.3, Texel sizes, compatibility classes, and pixel format/type combinations for each image format. Class (a) is for 11/11/10 packed floating-point formats; class (b) is for 10/10/10/2 packed formats. Implementations may support a limited combined number of image units and active fragment shader outputs (section 4.2.1). A link error will be generated if the number of active image uniforms used in all shaders and the number of active fragment shader outputs exceeds the implementation- dependent value (MAX_COMBINED_IMAGE_UNITS_AND_FRAGMENT_OUTPUTS). Modify Section 3.12.2, Shader Execution, p. 274 (add new unnumbered subsection section at the end of the section, p. 279) Early Fragment Tests An explicit control is provided to allow fragment shaders to enable early fragment tests. If the fragment shader specifies the "early_fragment_tests" layout qualifier, the per-fragment tests described in Section 3.X will be performed prior to fragment shader execution. Otherwise, they will be performed after fragment shader execution. Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification (Per-Fragment Operations and the Framebuffer) None. Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification (Special Functions) Modify Section 5.4.1, Commands Not Usable In Display Lists (p. 358) (add "MemoryBarrier" to the list of commands not allowed in a display list, in the "Buffer objects" paragraph) Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification (State and State Requests) Modify Section 6.1.3, Enumerated Queries (p. 369) (modify 2nd pargraph, p. 370) ... must be TEXTURE_RESIDENT, IMAGE_FORMAT_COMPATIBILITY_TYPE, or one of the symbolic values in table 3.22. New Implementation Dependent State Minimum Get Value Type Get Command Value Description Sec. Attrib --------- ---- ----------- -------- ----------------------- ---- ------ MAX_IMAGE_UNITS Z+ GetIntegerv 8 number of units for 3.9.X - image load/store/atom MAX_COMBINED_IMAGE_UNITS_ Z+ GetIntegerv 8 limit on active image 3.9.X - AND_FRAGMENT_OUTPUTS units + fragment outputs MAX_IMAGE_SAMPLES Z GetIntegerv 0 max allowed samples 3.9.X - for a texture level bound to an image unit MAX_VERTEX_IMAGE_ Z+ GetIntegerv 0 number of image variables 2.14.7 UNIFORMS in vertex shaders MAX_TESS_CONTROL_IMAGE_ Z+ GetIntegerv 0 number of image variables 2.14.7 UNIFORMS in tess. control shaders MAX_TESS_EVALUATION_IMAGE_ Z+ GetIntegerv 0 number of image variables 2.14.7 UNIFORMS in tess. eval. shaders MAX_GEOMETRY_IMAGE_ Z+ GetIntegerv 0 number of image variables 2.14.7 UNIFORMS in geometry shaders MAX_FRAGMENT_IMAGE_ Z+ GetIntegerv 8 number of image variables 2.14.7 UNIFORMS in fragment shaders MAX_COMBINED_IMAGE_ Z+ GetIntegerv 8 number of image variables 2.14.7 UNIFORMS in all shaders New State Add to Table 6.22, Textures (state per texture object), p. 414 Get Value Type Get Command Initial Value Description Sec Attribute --------------------- ----- ----------- ------------- ------------------------ ----- --------- IMAGE_FORMAT_ Z_2 GetTexParam- see 3.9.x compatibility rules for 3.9.X texture COMPATIBILITY_TYPE eteriv texture use with image units Add a new Table 6.X, Image Stage (state per image unit) Get Value Type Get Command Initial Value Description Sec Attribute --------------------- ---- ----------- ------------- ------------------------ ----- --------- IMAGE_BINDING_NAME 8*xZ+ GetIntegeri_v 0 name of bound texture 3.9.X none object IMAGE_BINDING_LEVEL 8*xZ+ GetIntegeri_v 0 level of bound texture 3.9.X none object IMAGE_BINDING_LAYERED 8*xB GetBooleani_v FALSE texture object bound w/ 3.9.X none multiple layers IMAGE_BINDING_LAYER 8*xZ+ GetIntegeri_v 0 layer of bound texture 3.9.X none object, if not layered IMAGE_BINDING_ACCESS 8*xZ3 GetIntegeri_v READ_ONLY read and/or write access 3.9.X none for bound texture IMAGE_BINDING_FORMAT 8*xZ+ GetIntegeri_v R8 format used for accesses 3.9.X none to bound texture Additions to Appendix A of the OpenGL 3.2 (Compatibility Profile) Specification (Invariance) Modify Section A.1, Repeatability (p. 454) (add a new sentence to the end of the first paragraph, p. 454) ... For any given GL and framebuffer state vector .. whenever the command is executed on that initial GL and framebuffer state. This repeatability requirement doesn't apply when using shaders containing side effects (image stores, image atomic operations, atomic counter operations), because these memory operations are not guaranteed to be processed in a defined order. Modify Section A.3, Invariance (p. 455) (add new language to the end of the section, p. 457) If a sequence of GL commands specifies primitives to be rendered with shaders containing side effects (image stores, image atomic operations, atomic counter operations), invariance rules are relaxed. In particular, Rule 1, Corollary 3, and Rule 4 do not apply in the presence of shader side effects. The following weaker versions of Rule 1 and 4 apply to GL commands involving shader side effects: Rule 6: For any given GL and framebuffer state vector, and for any given GL command, the contents of any framebuffer state not directly or indirectly affected by results of shader image stores, atomic operations, or atomic counter operations must be identical each time the command is executed on that initial GL and framebuffer state. Rule 7: The same vertex or fragment shader will produce the same result when run multiple times with the same input as long as: * shader invocations do not use image atomic operations or atomic counters; * no framebuffer memory is written to more than once by image stores, unless all such stores write the same value; and * no shader invocation, or other operation performed to process the sequence of commands, reads memory written to by an image store. When any sequence of GL commands triggers shader invocations that perform image stores, atomic operations, or atomic counter operations, and subsequent GL commands read the memory written by those shader invocations, these operations must be explicitly synchronized. For more details, see Section 2.14.X, Shader Memory Access. Modify Section A.3, Invariance (p. 455) Add Section A.5, Shader Image Load, Store, and Atomic Invariance (p. 457) Additions to Appendix D of the OpenGL 3.2 (Compatibility Profile) Specification (Invariance) Modify Section D.3, Propagating State Changes, p. 467 (add to list of bullets at the end of the section, p. 467) * Rendering commands that trigger shader invocations, where the shader performs image stores or atomic operations. Additions to the AGL/GLX/WGL Specifications None. GLX Protocol !!! TBD !!! NOTE TO PROTOCOL CREATORS: Don't attempt to use the same protocol for BindImageTexture and BindImageTextureEXT (from EXT_shader_image_load_store). BindImageTexture throws an error on negative and values; BindImageTextureEXT does not. Modifications to the OpenGL Shading Language Specification, Version 1.50 Including the following line in a shader can be used to control the language features described in this extension: #extension GL_ARB_shader_image_load_store : where is as specified in section 3.3. New preprocessor #defines are added to the OpenGL Shading Language: #define GL_ARB_shader_image_load_store 1 Modify Section 3.6, Keywords, p. 14 (add the following to the list of keywords, p. 14) coherent volatile restrict readonly writeonly image1D iimage1D uimage1D image2D iimage2D uimage2D image3D iimage3D uimage3D image2DRect iimage2DRect uimage2DRect imageCube iimageCube uimageCube imageBuffer iimageBuffer uimageBuffer image1DArray iimage1DArray uimage1DArray image2DArray iimage2DArray uimage2DArray imageCubeArray iimageCubeArray uimageCubeArray image2DMS iimage2DMS uimage2DMS image2DMSArray iimage2DMSArray uimage2DMSArray (remove from the list of reserved keywords, p. 15) volatile Add all these types into the basic types table, in the opaque sections, along with their corresponding texture types. (Insert a new section immediately after Section 4.1.7, Samplers, p. 23) Section 4.1.X, Images Like samplers, images are opaque handles to one-, two-, or three-dimensional images corresponding to all or a portion of a single level of a texture image bound to an image unit. There are distinct image variable types for each texture target, and for each of float, integer, and unsigned integer data types. Image accesses should use an image type that matches the target of the texture whose level is bound to the image unit, or for non-layered bindings of 3D or array images should use the image type that matches the dimensionality of the layer of the image (i.e. a layer of 3D, 2DArray, Cube, or CubeArray should use image2D, a layer of 1DArray should use image1D, and a layer of 2DMSArray should use image2DMS). If the image target type does not match the bound image in this manner, if the data type does not match the bound image, or if the format layout qualifier does not match the image unit format as described in Section 3.9.X of the OpenGL Specification, the results of image accesses are undefined but cannot include program termination. Image variables are used in the image load, store, and atomic functions described in Section 8.X, "Image Functions" to specify an image to access. They can only be declared as function parameters or uniform variables (see Section 4.3.5 "Uniform"). Except for array indexing, structure field selection, and parentheses, images are not allowed to be operands in expressions. Images may be aggregated into arrays within a shader (using square brackets [ ]) and can be indexed with general integer expressions. The results of accessing an image array with an out-of-bounds index are undefined. Images cannot be treated as l-values; hence, they cannot be used as out or inout function parameters, nor can they be assigned into. As uniforms, they are initialized only with the OpenGL API; they cannot be declared with an initializer in a shader. As function parameters, images may only be passed to samplers of matching type. Add Memory Qualifier Table to Section 4.3, Storage Qualifiers, p. 29 Only variables declared as image types (the basic opaque types with "image" in their keyword) can be qualified with a memory qualifier. Variables declared as image types can qualified with one or more of the following memory qualifiers: Qualifier Meaning ------------ ------------------------------------------------- coherent memory variable where reads and writes are coherent with reads and writes from other shader invocations volatile memory variable whose underlying value may be changed at any point during shader execution by some source other than the current shader invocation restrict memory variable where use of that variable is the only way to read and write the underlying memory in the relevant shader stage readonly memory variable that can be used to read the underlying memory, but cannot be used to write the underlying memory writeonly memory variable that can be used to write the underlying memory, but cannot be used to read the underlying memory Modify Section 4.3.2, Constant Qualifier (p. 30) (add after last paragraph of section) Because image variables can not be built from constant expressions, the "const" qualifier may not be used to create a compile-time constant image variable. Modify Section 4.3.8.1 (Input Layout Qualifiers), p. 39 Remove "only" from the sentence: Fragment shaders can have an input layout only for redeclaring the built-in variable gl_FragCoord... Add to the end of the section: Fragment shaders also allow the following layout qualifier on "in" only (not with variable declarations): layout-qualifier-id early_fragment_tests to request that fragment tests be performed before fragment shader execution, as described in Section 3.12.2 of the OpenGL Specification. For example, layout(early_fragment_tests) in; Specifying this will make per-fragment tests be performed before fragment shader execution. If this is not declared, per-fragment tests will be performed after fragment shader execution. (Insert immediately after Section 4.3.8.3, Uniform Block Layout Qualifiers, p. 40) Section 4.3.8.X, Image Layout Qualifiers Format layout qualifiers can be used on image variable declarations (those declared with a basic type having “image” in its keyword). The format layout qualifier identifiers for image variable declarations are : : rgba32f rgba16f rg32f rg16f r11f_g11f_b10f r32f r16f rgba16 rgb10_a2 rgba8 rg16 rg8 r16 r8 rgba16_snorm rgba8_snorm rg16_snorm rg8_snorm r16_snorm r8_snorm : rgba32i rgba16i rgba8i rg32i rg16i rg8i r32i r16i r8i : rgba32ui rgba16ui rgb10_a2ui rgba8ui rg32ui rg16ui rg8ui r32ui r16ui r8ui A format layout qualifier specifies the image format associated with a declared image variable. Only one format qualifier may be specified for any image variable declaration. For image variables with floating-point component types (image*), signed integer component types (iimage*), or unsigned integer component types (uimage*), the format qualifier used must match the , , or grammar rules, respectively. It is an error to declare an image variable where the format qualifier does not match the image variable type. Any image variable used for image loads or atomic operations must specify a format layout qualifier; it is an error to pass an image uniform variable or function parameter declared without a format layout qualifier to an image load or atomic function. Uniforms not qualified with "writeonly" must have a format layout qualifier. Note that an image variable passed to a function for read access cannot be declared as "writeonly" and hence must have been declared with a format layout qualifier. (Insert immediately after Section 4.3.9, Interpolation, p. 42) Section 6.1.1 Function Calling Conventions Add "memory qualifier" as one of the qualifiers that can be used as a formal "parameter-qualifier". Section 4.3.X, Memory Access Qualifiers The "coherent", "volatile", "restrict", and "const" storage qualifiers can be specified in image variable declarations to control memory accesses using the declared variables. Memory accesses to image variables declared using the "coherent" storage qualifier are performed coherently with similar accesses from other shader invocations. In particular, when reading a variable declared as "coherent", the values returned will reflect the results of previously completed writes performed by other shader invocations. When writing a variable declared as "coherent", the values written will be reflected in subsequent coherent reads performed by other shader invocations. As described in the Section 2.20.X of the OpenGL Specification, shader memory reads and writes complete in a largely undefined order. The built-in function memoryBarrier() can be used if needed to guarantee the completion and relative ordering of memory accesses performed by a single shader invocation. When accessing memory using variables not declared as "coherent", the memory accessed by a shader may be cached by the implementation to service future accesses to the same address. Memory stores may be cached in such a way that the values written may not be visible to other shader invocations accessing the same memory. The implementation may cache the values fetched by memory reads and return the same values to any shader invocation accessing the same memory, even if the underlying memory has been modified since the first memory read. While variables not declared as "coherent" may not be useful for communicating between shader invocations, using non-coherent accesses may result in higher performance. Memory accesses to image variables declared using the "volatile" storage qualifier must treat the underlying memory as though it could be read or written at any point during shader execution by some source other than the executing shader invocation. When a volatile variable is read, its value must be re-fetched from the underlying memory, even if the shader invocation performing the read had previously fetched its value from the same memory. When a volatile variable is written, its value must be written to the underlying memory, even if the compiler can conclusively determine that its value will be overwritten by a subsequent write. Since the external source reading or writing a "volatile" variable may be another shader invocation, variables declared as "volatile" are automatically treated as coherent. Memory accesses to image variables declared using the "restrict" storage qualifier may be compiled assuming that the variable used to perform the memory access is the only way to access the underlying memory using the shader stage in question. This allows the compiler to coalesce or reorder loads and stores using "restrict"-qualified image variables in ways that wouldn't be permitted for image variables not so qualified, because the compiler can assume that the underlying image won't be read or written by other code. Applications are responsible for ensuring that image memory referenced by variables qualified with "restrict" will not be referenced using other variables in the same scope; otherwise, accesses to "restrict"-qualified variables will have undefined results. Memory accesses to image variables declared using the "readonly" qualifier may only read the underlying memory, which is treated as read-only memory and cannot be written to. It is an error to pass an image variable qualified with "readonly" to imageStore() or other built-in functions that modify image memory. Memory accesses to image variables declared using the "writeonly" qualifier may only write the underlying memory; the underlying memory cannot be read. It is an error to pass an image variable qualified with "writeonly" to imageLoad() or other built-in functions that read image memory. The values of image variables qualified with "coherent", "volatile", "restrict", "readonly", or "writeonly" may not be passed to functions whose formal parameters lack such qualifiers. (See section 6.1 “Function Definitions” for more detail on function calling.) It is legal to have additional qualifiers on a formal parameter, but not to have fewer. vec4 funcA(layout(rgba32f) image2D restrict a) { ... } vec4 funcB(layout(rgba32f) image2D a) { ... } layout(rgba32f) uniform image2D img1; layout(rgba32f) coherent uniform image2D img2; funcA(img1); // OK, adding "restrict" is allowed funcB(img2); // illegal, stripping "coherent" is not Layout qualifiers cannot be used on formal function parameters, but they are not included in parameter matching. Note that the use of "const" in an image variable declaration is qualifying the const-ness of variable being declared, not the image it refers to: The qualifier "readonly" qualifies the image memory (as accessed through that variable) while "const" qualifiers the variable itself. Modify Section 7.4, Built-In Constants, p. 74 (Add the following new constants.) const int gl_MaxImageUnits = 8; const int gl_MaxCombinedImageUnitsAndFragmentOutputs = 8; const int gl_MaxImageSamples = 0; const int gl_MaxVertexImageUniforms = 0; const int gl_MaxTessControlImageUniforms = 0; const int gl_MaxTessEvaluationImageUniforms = 0; const int gl_MaxGeometryImageUniforms = 0; const int gl_MaxFragmentImageUniforms = 8; const int gl_MaxCombinedImageUniforms = 8; (Insert a new numbered section at the end of Chapter 8, Built-in Functions, p. 69) Section 8.X, Image Functions Variables using one of the image data types may be used in the built-in shader image memory functions defined in this section to read and write individual texels of a texture. Each image variable references an image unit, which has a texture image attached. When image memory functions access memory, an individual texel in the image is identified using an i, (i,j), or (i,j,k) coordinate corresponding to the values of . For image2DMS and image2DMSArray variables (and the corresponding int/unsigned int types) corresponding to multisample textures, each texel may have multiple samples and an individual sample is identified using the integer parameter. The coordinates and sample number are used to select an individual texel in the manner described in Section 3.9.X of the OpenGL specification. Loads and stores support float, integer, and unsigned integer types. The data types "gimage*" serve as placeholders meaning either "image*", "iimage*", or "uimage*" in the same way as "gvec" or "gsampler". The "IMAGE_INFO" in the prototypes below is a placeholder representing 33 separate functions, each for a different type of image variable. The "IMAGE_INFO" placeholder is replaced by one of the following parameter lists: gimage1D image, int coord gimage2D image, ivec2 coord gimage3D image, ivec3 coord gimage2DRect image, ivec2 coord gimageCube image, ivec3 coord gimageBuffer image, int coord gimage1DArray image, ivec2 coord gimage2DArray image, ivec3 coord gimageCubeArray image, ivec3 coord gimage2DMS image, ivec2 coord, int sample gimage2DMSArray image, ivec3 coord, int sample (Note that each of the "gimage*" lines represents one of three different image variable types.) Syntax: gvec4 imageLoad(readonly IMAGE_INFO); Description: Loads the texel at the coordinate from the image unit specified by . For multisample loads, the sample number is given by . When , , and identify a valid texel, the bits used to represent the selected texel in memory are converted to a vec4, ivec4, or uvec4 in the manner described in Section 3.9.X of the OpenGL Specification and returned. Syntax: void imageStore(writeonly IMAGE_INFO, gvec4 data); Description: Stores the value of into the texel at the coordinate from the image specified by . For multisample stores, the sample number is given by . When , , and identify a valid texel, the bits used to represent are converted to the format of the image unit in the manner described in Section 3.9.X of the OpenGL Specification and stored to the specified texel. Syntax: uint imageAtomicAdd(IMAGE_INFO, uint data); int imageAtomicAdd(IMAGE_INFO, int data); uint imageAtomicMin(IMAGE_INFO, uint data); int imageAtomicMin(IMAGE_INFO, int data); uint imageAtomicMax(IMAGE_INFO, uint data); int imageAtomicMax(IMAGE_INFO, int data); uint imageAtomicAnd(IMAGE_INFO, uint data); int imageAtomicAnd(IMAGE_INFO, int data); uint imageAtomicOr(IMAGE_INFO, uint data); int imageAtomicOr(IMAGE_INFO, int data); uint imageAtomicXor(IMAGE_INFO, uint data); int imageAtomicXor(IMAGE_INFO, int data); uint imageAtomicExchange(IMAGE_INFO, uint data); int imageAtomicExchange(IMAGE_INFO, int data); uint imageAtomicCompSwap(IMAGE_INFO, uint compare, uint data); int imageAtomicCompSwap(IMAGE_INFO, int compare, int data); Description: These functions perform atomic operations on individual texels or samples of an image variable. Atomic memory operations read a value from the selected texel, compute a new value using one of the operations described below, write the new value to the selected texel, and return the original value read. The contents of the texel being updated by the atomic operation are guaranteed not to be updated by any other image store or atomic function between the time the original value is read and the time the new value is written. As with image load and store functions, , , and specify the individual texel to operate on. The method for identifying the individual texel operated on from , , and , and the method for reading and writing the texel are specified in Section 3.9.X of the OpenGL specification. Atomic memory operations are supported on only a subset of all image variable types; must be either: * an image variable with signed integer components (iimage*) and a format qualifier of "r32i", or * an image variable with unsigned integer components (uimage*) and a format qualifier of "r32ui". imageAtomicAdd() computes a new value by adding the value of to the contents of the selected texel. These functions support 32-bit unsigned integer operands and 32-bit signed integer operands. imageAtomicMin() computes a new value by taking the minimum of the value of and the contents of the selected texel. These functions support 32-bit signed and unsigned integer operands. imageAtomicMax() computes a new value by taking the maximum of the value of and the contents of the selected texel. These functions support 32-bit signed and unsigned integer operands. imageAtomicAnd() computes a new value by performing a bitwise and of the value of and the contents of the selected texel. These functions support 32-bit signed and unsigned integer operands. imageAtomicOr() computes a new value by performing a bitwise or of the value of and the contents of the selected texel. These functions support 32-bit signed and unsigned integer operands. imageAtomicXor() computes a new value by performing a bitwise exclusive or of the value of and the contents of the selected texel. These functions support 32-bit signed and unsigned integer operands. imageAtomicExchange() computes a new value by simply copying the value of . These functions support 32-bit signed and unsigned integer operands. imageAtomicCompSwap() compares the value of and the contents of the selected texel. If the values are equal, the new value is given by ; otherwise, it is taken from the original value loaded from the texel. These functions support 32-bit signed and unsigned integer operands. (Insert another new numbered section at the end of Chapter 8, Built-in Functions, p. 69) Section 8.Y, Shader Memory Control Functions Shaders of all types may read and write the contents of textures and buffer objects using image variables. While the order of reads and writes visible to a single shader invocation is well-defined, the relative order of reads and writes to a single shared memory address from multiple separate shader invocations is largely undefined. Additionally, the order of accesses to multiple memory addresses performed by a single shader invocation, as observed by other shader invocations, is also undefined. Syntax: void memoryBarrier(void); Description: memoryBarrier() can be used to control the ordering of memory transactions issued by a single shader invocation. When called, memoryBarrier() will wait on the completion of all memory accesses resulting from the use of image variables or atomic counters and then return to the caller with no other effect. When this function returns, the results of any memory stores performed using coherent variables performed prior to the call will be visible to any future coherent memory access to the same addresses from other shader invocations. In particular, the values written this way in one shader stage are guaranteed to be visible to coherent memory accesses performed by shader invocations in subsequent stages when those invocations were triggered by the execution of the original shader invocation (e.g., fragment shader invocations for a primitive resulting from a particular geometry shader invocation). Modify Section 9, Shading Language Grammar (p. 105) !!! TBD: Add grammar constructs for memory access qualifiers. Errors INVALID_VALUE is generated by Uniform1i{v} if the location refers to an image variable and the value specified is less than zero or greater than or equal to the value of MAX_IMAGE_UNITS. INVALID_OPERATION is generated by Uniform* functions other than Uniform1i{v} if the location refers to an image variable. INVALID_VALUE is generated by BindImageTexture if is greater than or equal to the value of MAX_IMAGE_UNITS. INVALID_VALUE is generated by BindImageTexture if is not the name of an existing texture object. INVALID_VALUE is generated by BindImageTexture if is not a legal format. Dependencies on OpenGL 3.2 (Core Profile) If only the core profile of OpenGL 3.2 is supported, references to buffer objects for conventional vertex attributes and to the Begin and RasterPos commands should be removed. Dependencies on OpenGL 3.1, ARB_uniform_buffer_object, and EXT_bindable_uniform If OpenGL 3.1, ARB_uniform_buffer_object, and EXT_bindable_uniform are not supported, references to UNIFORM_BARRIER_BIT should be removed. Dependencies on ARB_draw_indirect If ARB_draw_indirect is not supported, references to COMMAND_BARRIER_BIT should be removed. Dependencies on NV_vertex_buffer_unified_memory If NV_vertex_buffer_unified_memory is not supported, references to that extension and GPU addresses in the discussion of VERTEX_ATTRIB_ARRAY_BARRIER_BIT and ELEMENT_ARRAY_BARRIER_BIT should be removed. Dependencies on NV_parameter_buffer_object If NV_parameter_buffer_object is not supported, references to ProgramBufferParametersNV in the discussion of BUFFER_UPDATE_PARAMETER_BIT should be removed. Dependencies on OpenGL 3.2 and ARB_texture_multisample If OpenGL 3.2 and ARB_texture_multisample are not supported, references to multisample textures should be removed. Dependencies on OpenGL 4.0 and ARB_sample_shading If OpenGL 4.0 or ARB_sample_shading is supported, the discussion of the number of shader invocations for a given fragment in the "Shader Memory Access" section of the specification should be updated to discuss the sample shading enable and the minimum sample shading factor provided in that extension. Dependencies on OpenGL 4.0 and ARB_texture_cube_map_array If OpenGL 4.0 or ARB_texture_cube_map_array are not supported, references to cube map array textures should be removed. Dependencies on OpenGL 3.3 and ARB_texture_rgb10_a2ui If OpenGL 3.3 or ARB_texture_rgb10_a2ui are not supported, references to the RGB10_A2UI texture format should be removed. Dependencies on NV_shader_buffer_load If NV_shader_buffer_load is supported, the new section 2.14.X (Shader Memory Access) should be combined with "Section 2.20.X, Shader Memory Access" from NV_shader_buffer_load. Dependencies on OpenGL 4.0, ARB_gpu_shader5, and NV_gpu_shader5 If OpenGL 4.0, ARB_gpu_shader5, and NV_gpu_shader5 are not supported, the modifications to the OpenGL Shading Language Specification should be removed. Dependencies on OpenGL 4.0 and ARB_tessellation_shader If OpenGL 4.0 and ARB_tessellation_shader are not supported, references to tessellation control and evaluation shaders should be removed. Dependencies on EXT_shader_atomic_counters and ARB_shader_atomic_counters If EXT_shader_atomic_counters is not supported, remove references to atomic counters and ATOMIC_COUNTER_BARRIER_BIT. Dependencies on EXT_depth_bounds_test If EXT_depth_bounds_test is not supported, references to the depth bounds test should be removed. Dependencies on ARB_separate_shader_objects If ARB_separate_shader_objects is supported, early depth tests are enabled if and only if (a) there is an active program for the fragment shader stage and (b) the fragment shader in that program enables early depth tests using a layout qualifier. Dependencies on EXT_shader_image_load_store Both this extension and EXT_shader_image_load_store provide nearly the identical functionality. If both extensions are enabled in the shading language, the "size*" layout qualifiers are treated as format qualifiers, and are mapped to equivalent format qualifiers in the table below, according to the type of image variable. Additionally, if both extensions are enabled in the shading language, size/format layout qualifiers need not be specified for image variables used exclusively for stores. image* iimage* uimage* -------- -------- -------- size1x8 n/a r8i r8ui size1x16 r16f r16i r16ui size1x32 r32f r32i r32ui size2x32 rg32f rg32i rg32ui size4x32 rgba32f rgba32i rgba32ui Issues (0) How does this extension differ from the similar EXT_shader_image_load_store? RESOLVED: The functionality provided by this extension is very similar to that provided by EXT_shader_image_load_stores. There are some functional differences. * "size" layout qualifiers replaced with "format" qualifiers. * Image loads aren't restricted to "1x8", "1x16", "1x32", "2x32", and "4x32" formats. Instead, each supported image format has a layout qualifier, and values loaded from images are converted to an vec4/ivec4/uvec4 representation appropriate for the image format. * For textures not allocated by the GL (e.g., images shared from other external APIs), implementations need not support image unit formats that don't match the texture format, unless they are in the same "class", which is generally the case only if component counts and sizes are exactly the same. * Image variables used exclusively for image stores need not declare a format qualifier. * Added the built-in GLSL constants "gl_MaxImageUnits", "gl_MaxCombinedImageUnitsAndFragmentOutputs", and "gl_MaxImageSamples". * BindImageTexture throws INVALID_VALUE if or is negative. * The parameter of BindImageTexture was changed from an "int" to an "enum". In the EXT, copied TexImage*'s parameter, which is an "int" because that's how it was defined in OpenGL 1.0 (where the parameter was called and the now-deprecated "1", "2", "3", and "4" formats were the only ones supported). * Added implemenentation-dependent limits on the number of active image uniforms (MAX_*_IMAGE_UNIFORMS) for each stage, and combined across all stages. Also added corresponding GLSL constants "gl_Max*ImageUniforms". * The atomicIncWrap() and atomicDecWrap() built-in functions present in the EXT have been removed. * The parameter of BindImageTextureEXT has been renamed to for BindImageTexture. (1) How are the format and type of the load/store determined? RESOLVED: There is a natural desire to load and store using a canonical 4-vector in the shader with hardware converting to/from a format compatible with the bound image, to be consistent with how texture loads and fragment shader outputs currently behave. There is also good reason to allow some flexibility in the format used for image accesses being different from the internal format of the texture level. We allow format conversions to and from any format that image units support. We make the format be selected when the image is bound to an image unit, and define which image unit formats can be used for which texture level internal formats. For example, it is legal to access an image whose internal format is RGBA8 with an image unit format of R32UI. (2) What set of texture formats should be supported for image loads and stores? RESOLVED: We allow textures to be bound to image units using only a subset of supported formats, to limit the amount of hardware support required for image operations. Any texture formats not explicitly enumerated in this extension may not be bound to an image unit, although future extensions may add new formats to the set of supported formats. In particular, this extension supports one-, two-, and four-component textures with 8-, 16-, and 32-bit components, including floating-point, signed integer, unsigned integer, as well as signed and unsigned normalized formats. Additionally, a small number of other formats are supported, including the 11/11/10 RGB format from EXT_packed_float and 10/10/10/2 unsigned normalized RGBA. (3) Should we general support image loads and stores for three-component "RGB" formats? RESOLVED: Not in this extension. If an application needs to perform image loads and stores on a three-component texture, it could use an equivalent RGBA format and ignore the alpha component. The EXT_texture_swizzle extension could be used to make the values returned by texture appear identical to an RGB texture, if required. (4) Should textures be unbound from image units when they are deleted? RESOLVED: Yes, this matches behavior of existing bind points. (5) Should we support image loads and stores for the deprecated LUMINANCE, LUMINANCE_ALPHA, and ALPHA formats? RESOLVED: No, only support the RGBA-style formats. EXT_texture_swizzle can be used to mimic luminance and alpha if required. (6) Should we support 64-bit atomics on images? Should we support atomics at all on formats with 8-, 16-, 64-, or 128-bit texels? RESOLVED: No, we will only support 32-bit atomic operations on images. (7) How do shader image loads and stores interact with texture completeness? What happens if you bind a texture with inconsistent mipmaps? RESOLVED: The image unit is treated as if nothing were bound, where all accesses are treated as invalid. (8) What happens if the value passed to Uniform1i to specify the image unit corresponding to a image variable refers to a non-existent image unit (i.e., is negative or greater than or equal to the number of image units supported)? RESOLVED: Values referring to invalid image units will be rejected and produce an INVALID_VALUE error. (9) Should we provide counting rules for image variable use in different shaders like we have for samplers? In particular, there are limits on the amount of state, the number of active samplers in each shader stage, and the sum of the active sampler counts in each stage. RESOLVED: No. It was considered sufficient to have just a limit on the total number of image units in the implementation (i.e., the number of distinct values that the variable can be set to). (10) Can this extension be used to load and store values into a buffer object? Into a renderbuffer? RESOLVED: Yes, indirectly. The BUFFER_TEXTURE target provided by OpenGL 3.0 and the EXT_texture_buffer_object extension allows an application to create a one-dimensional buffer texture using the data store of a buffer object. This buffer texture may be bound to an image unit and accessed with an imageBuffer variable in the Shading Language. This extension adds support for image accesses to multisample textures, but not renderbuffers. Note that with the ARB_texture_multisample extension, there is no longer a good reason to use renderbuffers. Existing 2D or rectangle targets already provided a superset of single- sample renderbuffer functionality; the new ARB extension provides a superset of multisample renderbuffer functionality. (11) What amount of automatic synchronization is provided for image loads and stores? In particular, is the use of MemoryBarrier() required to ensure consistent ordering relative to other GL operations? Or is some other mechanism (e.g., unbinding a texture from an image unit and then binding it to a texture image unit) sufficient? RESOLVED: Use of MemoryBarrier is required, and there is no automatic synchronization when images are bound or unbound. Implicit synchronization is difficult, as it might require some combination of: - tracking which images might be written (randomly) in the shader itself; - assuming that if a shader that performs writes is executed, all texels of all bound images could be modified and thus must be treated as dirty; - idling at the end of each primitive or draw call, so that the results of all previous commands are complete. Since normal OpenGL operation is pipelined, idling would result in a significant performance impact since pipelining would otherwise allow fragment shader execution for draw call N while simultaneously performing vertex shader execution for draw call N+1. (12) Should image loads and stores be allowed for all shader types? RESOLVED: Yes, it seems useful. Note that some shader types pose specific implementation complexities (e.g., reuse of vertices in vertex shaders, number of fragment shader invocations in multisample modes, relative order of execution within and between shader groups). We have explicitly specify several cases where the invocation count and execution order are undefined. While these cases may be a problem for some algorithms, we expect that many algorithms will not be adversely impacted. (13) Should an implementation be required to throw INVALID_OPERATION errors if the dimension of the texture coordinates implied by the image variable type doesn't match the structure of the texture level/layer bound to the corresponding image unit? If not, what happens in such a mismatch? RESOLVED: No. The results of image accesses are undefined. (14) Should shader image variable types include a "format" implying the data type accepted/returned by shader image loads and stores? For example, an image variable corresponding to a 2D texture with format of RGBA32F might have a type "image2Dvec4", with the "vec4" indicating that the image data lines up with a four-component floating-point vector. RESOLVED: No. Separate types are provided for float vs. int vs. unsigned int, but not for each image format. However, format qualifiers associated with image variables can (and in many cases must) be used to associate a format with an image variable. (15) If shader image variable types include information on the texel components returned or written by shader image accesses, should an implementation be required to enforce errors if the variable type is incompatible with the format of the referenced texture? If not, or if the image variable type doesn't include format information, what happens in case of a mismatch between the texture format and the shader access format? RESOLVED: We aren't including types in the variable that correspond to the image format, so an error check in the driver is not possible. If an individual load, store, or atomic uses a data type incompatible with the texture bound to the image unit, loads will return and stores will write undefined values. (16) Is it possible to bind the "default texture" (numbered zero) for a given texture target to an image unit? RESOLVED: No. Passing zero to BindImageTexture unbinds and texture currently bound to the selected image unit. If this ability were provided, it would also be necessary to provide some mechanism to specify a texture target because there is a separate default "zero" texture for each target. Note that existing framebuffer objects have a similar behavior; default textures can't be attached to an FBO. (17) May bordered textures be used with image loads and stores? RESOLVED: No. (18) Should we have defined behavior if invalid coordinates are passed to an image load, store, or atomic operation? If so, what happens? RESOLVED: Yes. We define the behavior to return zeroes on a load and atomic and to have no effect on any bound texture on stores and atomics. (19) Should we have a limit on the total number of combined image units and draw buffers, and if so, what should that be? RESOLVED: Yes, some hardware requires this. The program will fail to link. (20) What happens if a shader specifies an image store or atomic operation for killed/discarded pixels? RESOLVED: For GLSL shaders that execute a "discard" instruction, any image stores or atomics performed before executing the discard will behave normally. When the "discard" instruction is executed, the shader invocation will be terminated and will perform no further image store or atomic operations. (21) When enabling early depth tests in a program, what happens if a fragment fails one of the tests (e.g., depth test)? RESOLVED: The specification indicates that the fragment shader is not executed. Implementations might still end up running fragment shader for implementation-dependent reasons. For example, the fragment shader may be run in order to approximate derivatives for neighboring pixels that did pass all per-fragment tests. In these cases, implementations must guarantee that image stores have no effect. (22) If implementations run fragment shaders for fragments that aren't covered by the primitive or fail early depth tests (e.g., "helper pixels"), how does that interact with stores and atomics? RESOLVED: The current OpenGL specification has no formal notion of "helper" pixels. In practice, implementations may run fragment shaders for pixels near the boundaries of rasterized primitives to allow derivatives to be approximated by differencing. Typically, these shader invocations have no effect. While they may produce outputs, the outputs for these pixels will be discarded without affecting the framebuffer. The spec basically treats these shader invocations as though they don't exist. If such a shader invocation performs store or atomic operations, we need to define what happens. In our definition, stores will have no effect, atomics will not update memory, and the values returned by atomics will be undefined. The fact that these invocations don't affect memory is consistent with the notion of helper pixel shader invocations not existing. However, it is possible to write a fragment shader where flow control depends on the (undefined) values returned by the atomic. In this case, the undefined values returned for helper pixels could result in very long execution time (appearing to be hang) or an infinite loop. To avoid hangs in such cases, it is possible to use the fragment shader input sample mask to identify helper pixels: // If the input sample mask is non-zero, at least one sample is // covered and the invocation should be treated as a real invocation. // If the sample mask is zero, nothing is covered and this should be // treated as a helper pixel. If more than 32 samples are supported, // additional words of gl_SampleMaskIn would need to be checked. if (gl_SampleMaskIn[0] != 0) { // "real" pixel, perform atomic operations } else { // "helper" pixel, skip atomics } It may be desirable to formalize the notion of helper pixels in a future addition to the shading language. (23) What API should we use to specify early depth tests? RESOLVED: Use a layout qualifier in a fragment shader rather than having a separate program parameter or other piece of GL state. (24) For formatted loads where the format doesn't include some component, what values are filled in? (0,0,0,1)? (0,0,0,0)? RESOLVED: Prefer (0,0,0,1) to match other APIs. (25) How does the combined-image-and-fragment-output limit interact with separate shader objects? For example, an application may want to share a single image unit between two shader stages and not have it count twice against the limit. RESOLVED: The known implementations of this extension do not have this issue, so we chose not to include any spec language. Perhaps a Begin-time error could be specified in the future if this limit is exceeded. (26) What sort of qualifiers should we provide relevant to memory referenced by image variables? RESOLVED: We will support the qualifiers "coherent", "volatile", "restrict", and "const" to be used in image variable declarations. "coherent" is used to ensure that memory accesses from different shader invocations are cached coherently (i.e., one invocation will be able to observe writes from another when the other invocation's writes complete). This coherence may mean the use of "coherent"-qualified image variables may perform more slowly than of otherwise equivalent unqualified variables. "volatile" behaves as in C, and may be needed if an algorithm requires reading image memory that may be written asynchronously by other shader invocations. "restrict" behaves as in the C99 standard, and can be used to indicate that no other image variable points to the same underlying data. This permits optimizations that would otherwise be impossible if the compiler has to assume that a pair of images might end up pointing to the same data. For example, in standard C/C++, a loop like: int *a, *b; a[0] = b[0] + b[0]; a[1] = b[0] + b[1]; a[2] = b[0] + b[2]; would need to reload b[0] for each assignment because a[0] or a[1] might point at the same data as b[0]. With restrict, the compiler can assume that b[0] is not modified by any of the instructions and load it just once. The same considerations apply to accesses using imageLoad(), imageStore(), and imageAtomic*() builtins. "const" behaves as in C, and indicates that the image memory should be treated as read-only. Note that the use of "const" in image variable declarations is different from the normal "const" qualifier, as it treats the image data referenced by the variable as constant. (27) How should shaders be able to express qualifiers for image variables? RESOLVED: This extension borrows from C/C++ syntax rules where a qualifier may be specified before or after the type. For example, layout(rgba32f) const uniform image2D imageVariable; declare an image uniform whose image data are treated as read-only. We permit qualifiers to be provided either before or after the type name (image2D). The position of the qualifier is meaningful. Qualifiers before the type name apply to the data referenced by the variable. Qualifiers after the type name apply to the variable itself. The closest C/C++ equivalent to the declarations above would turn declarations like: layout(rgba32f) const uniform image2D firstImage; layout(rgba32f) uniform image2D const secondImage; into: const struct image2D_data * firstImage; struct image2D_data * const secondImage; where "image2D" is replaced with "struct image2D_data *". In this model, the former declares to be a pointer to constant image data. The latter declares to be a constant pointer to non-constant image data. For "coherent", "volatile", and "const", the qualifier should typically go before the image type. For "restrict", the qualifier must go after the image type, since "restrict" applies to the pointer, not the data being pointed to. Note that a qualifier could theoretically be specified before and after the type name, such as: const image2D const imageVariable; which would declare to be constant and to reference constant image data. In this extension, declaring an image variable to be constant isn't meaningful, as such variables can never be used as l-values. (28) What is the meaning of "restrict" on a system that might run either multiple invocations of the same shader simultaneously, or multiple invocations of different shaders (vertex and fragment) simultaneously? RESOLVED: When an image variable is qualified with "restrict", the only guarantee is that no other image variable in the same shader invocation references the same underlying image data. There is no guarantee that the same image couldn't be referenced by another invocation of the same shader, or by an invocation of a different shader. The main function of "restrict" is to allow compilers to generate more efficient code for a single shader invocation than it could if it had to conservatively assume that accesses to other images could touch the same image data. (29) What is the purpose of the memoryBarrier() built-in function? RESOLVED: The memoryBarrier() function can be used to ensure that if another shader invocation or other portions observe image memory being written by a shader, that accesses appear in a predictable order. For example, consider the following code: uniform imageBuffer buf1; uniform imageBuffer buf2; int offset1, offset2; vec4 data1, data2; imageStore(buf1, offset1, data1); imageStore(buf2, offset2, data2); This specification doesn't require that writes be committed to memory in the order specified in the shader. It is possible that another shader invocation or some other observer would see before seeing . If an algorithm involved multiple shader invocations with one possibly needing to wait on data written by another, observing in the second shader would not ensure that has been written. However, if memoryBarrier() were used, as in the following code, the second shader would have such a guarantee. imageStore(buf1, offset1, data1); memoryBarrier(); imageStore(buf2, offset2, data2); (30) What happens if the texel identified by the coordinates given to an image load, store, or atomic built-in doesn't exist? (i.e., coordinates are out of bounds) RESOLVED: The results of image loads return zero. Stores do not update image memory. Atomics do not update image memory and return zero. These same considerations apply if no texture is bound to an image unit, the texture is incomplete, and various other conditions. We do not ever apply wrap modes on image operations. (31) Why do we have a parameter on BindImageTexture? RESOLVED: It allows some amount of bit-casting, to view a texture with one format using another format. In addition to any benefits from viewing textures with a different format, it also permits atomics operations on some multi-component textures by allowing them to be viewed using R32I or R32UI formats. In the EXT_shader_image_load_store extension, there was an additional benefit to working around a more severe limitation on the set of formats supported for stores -- only formats like R8, R16, R32F, RG32F, RGBA32F are supported there. Other formats not supported there can be viewed as supported formats (e.g., RGBA8 could map to R32UI), with shader code doing any needed packing and unpacking. (32) Do we support image atomics on multi-component texture formats? RESOLVED: Only if the texture formats can be viewed as "R32I" or "R32UI" formats by using the parameter of BindImageTexture. Atomics do not operate on a component-by-component basis in this extension. (33) What happens if early fragment testing is enabled, the early depth test passes, and a fragment shader that computes a new depth value is executed? RESOLVED: The depth value produced by the fragment shader has no effect if early depth and stencil tests are enabled. The depth value computed by a fragment shader is used only by the post-fragment shader stencil and depth tests, and those tests always have no effect when early fragment tests is enabled. (34) How do early fragment tests interact with occlusion queries? RESOLVED: When early fragment tests are enabled, sample counting for occlusion queries also happens prior to fragment shader execution. Enabling early fragment tests can change the overall sample count, because samples killed by alpha test and alpha to coverage will still be counted if early fragment tests are enabled. (35) If we provide support for multiple active program objects (e.g., one containing a vertex shader, another containing a fragment shader, as in EXT_separate_shader_object), how will early fragment tests be handled? RESOLVED: The early fragment test enable should be taken from the active program object corresponding to the fragment shader stage. (36) When specifying a coordinate vector to specify a texel for a TEXTURE_1D_ARRAY target, what coordinate is used to specify the layer? RESOLVED: For GLSL functions, a two-component vector is specified and the second (y) component is used to select a layer. (37) How does the synchronization (or lack thereof) of shader accesses to buffer memory interact with accesses to mapped buffer memory? RESOLVED: Shader memory accesses are not automatically synchronized with MapBuffer. Mapping a buffer object will not guarantee that image stores or atomics issued by shaders triggered by rendering commands prior to the MapBuffer call are complete before returning a pointer to the application. This lack of synchronization is similar to what happens if you call MapBufferRange with MAP_UNSYNCHRONIZED_BIT set. However, if you call MemoryBarrier with BUFFER_UPDATE_BARRIER_BIT set prior to mapping the buffer object, the GL will manually synchronize, ensuring that all prior shader writes to a buffer are complete prior to any subsequent commands (including MapBuffer) accessing the buffer. Revision History Rev. Date Author Changes ---- -------- -------- ----------------------------------------------- 33 10/16/13 pbrown Update issue (20) to clarify that any image stores and atomics issued before a "discard" do have an effect. Update issue (22) to better define the behavior of stores and atomics on "helper" pixels and to suggest a workaround for shaders that need to use values returned by atomics (undefined for helper pixels) in flow control constructs. have an effect. 32 03/06/12 pbrown Fix the minimum values for GLSL built-ins gl_Max{Fragment,Combined}ImageUniforms to 8 to match the minimums for the API specification (bug 8673). 31 01/18/12 Jon Leech State table fix for IMAGE_FORMAT_COMPATIBILITY_TYPE (Bug 8430). 30 08/04/11 pbrown Remove imageAtomicIncWrap() and imageAtomicDecWrap() functions from the ARB extension (bug 7182). Rename the argument of BindImageTexture to (bug 7851). Fix typo in spec language describing out-of-bounds indexing of image arrays. 29 08/03/11 pbrown Clarify that negative values of and will generate errors even in cases where those parameters would ultimately have no effect (bug 7850). Add a note recommending that BindImageTexture not use the same protocol as its "EXT" equivalent due to differences in error behavior. 28 07/27/11 pbrown Document new implementation limits added in version 26 as differences from the EXT (bug 7805). 27 07/22/11 Jon Leech Remove unreachable error condition for negative (bug 7770). 26 07/22/11 pbrown Add implementation limits on the number of image uniforms used by each shader stage, and on the combined total of all stages, as well as corresponding GLSL constants (bug 7805). 25 06/20/11 johnk Sync. with core specification: adds writeonly, replaces "const" with "readonly", refers to all these as "memory qualifiers", includes semantics for calling functions. Minor non-functional edits to make them match. 24 06/19/11 pbrown Assign values for new enumerants. 23 06/18/11 pbrown Clarify that image variables can not be stored in uniform blocks. 22 06/07/11 pbrown Clarify that and are ignored when used with non-layered textures. Clarify that non-existent layer/face numbers make accesses invalid for both non-layered and layered bindings (bug 7721). 21 06/06/11 pbrown Add IMAGE_FORMAT_COMPATIBILITY_TYPE to state tables, add descriptions for IMAGE_BINDING* state table entries (bug 7689). 20 06/06/11 pbrown Clarify the language describing data type conversions for image loads/stores to indicate that we use the same general process as for TexImage and GetTexImage commands. For multisample textures used as images, TexImage commands do not specify image data and GetTexImage is not supported (bug 7249). 19 02/14/11 pbrown Remove the repeatability requirement (Appendix A.1) when using shaders with side effects (bug 7026). Clean up spec language describing GLSL's memoryBarrier() function, and add a dependency on atomic counter extensions to indicate that memoryBarrier() also applies to atomic counters (bug 7237). 18 02/13/11 Jon Leech Cleanup BindImageTexture language to match 4.2 core spec phrasing. 17 01/20/11 pbrown Clarify that the MAX* limits can be queried by GetInteger64v (bug 7225). Add INVALID_VALUE error for BindImageTexture if or is negative (bug 7226). Clarify language for MemoryBarrier's BUFFER_UPDATE_BARRIER_BIT (bug 7228). Update the parameter of BindImageTexture to be an "enum" instead of "int". The EXT used "int" to be compatible with TexImage, which itself derived to the deprecated "1", "2", "3", and "4" formats from OpenGL 1.0 (bug 7183). 16 01/20/11 pbrown Add GLSL built-in constants for implementation- dependent limits (bug 7234). 15 01/18/11 Jon Leech Fix typos from Bug 7235. 14 01/18/11 pbrown Add interaction with NV_parameter_buffer_object for ProgramBufferParametersNV (bug 7235). 13 01/05/11 Jon Leech Fix typos from Bug 7202. 12 12/17/10 johnk Minor tweaks for grammar and consistency that also apply to 1.5, that were generated while incorporating into 4.2 core. 11 12/14/10 pbrown Add edits to invariance and synchronization rules in Appendices A and D to account for side effects from shader execution (bug 7026). 10 12/14/10 pbrown Clean up issues section from changes in revisions 7-9. 9 12/14/10 pbrown Modify the layout qualifier behavior for image variables to specify a full GL-style format instead of component/bit counts (bug 6868), with loaded data converted to a canonical vector type according to the full format. Limited the amount of format mismatching allowed when binding textures allocated outside the GL to image units. Removed the requirement for layout qualifiers on image variables used only for image stores. 8 12/12/10 pbrown Additional minor spec errata fixes (bug 6991). 7 12/12/10 pbrown Fix minor spec errata (bug 6870). Removed interactions with NV_gpu_program5; this is already covered by the EXT version of the spec. 6 10/19/10 pdaniell ARBify in preparation for OpenGL 4.2 core. 5 09/17/10 pbrown Clean up the spec language specifying the mapping of coordinates to texels according to the texture target. For 1D arrays, GLSL wants the layer in the second component of a two-component vector while NV_gpu_program5 wants it in the third component of a four-component vector. Also clarify that single-layer bindings of an array or cube map texture use a target appropriate to the bound layer. 4 03/23/10 pbrown Add interaction with EXT_separate_shader_objects. Update issues section to include some issues left behind in NV_gpu_shader5 when specs were refactored. 3 03/21/10 pbrown Update spec overview, interactions, and issues sections; miscellaneous minor clarifications. 2 03/16/10 pbrown Add a separate #extension line for this extension; needed since the became packaged separately from ARB_gpu_shader5. Added C99-like "restrict" qualifier to indicate that an image variable won't share underlying image contents with any other variable. Added support for "const" qualifiers on images to allow indicate read-only image data. Added language describing the significance of the position of image variable qualifiers. Clarified rules on use of image variables as function parameters; adding qualifiers is OK, stripping them off is not. Updated image layout qualifier section to clarify that "size" layout qualifiers are required on both uniform and function parameter declarations. Added "const" qualifier on the image argument in imageLoad() prototypes. Updated extension names in dependency sections. Add support for stores to the RGB10_A2 texture format from OpenGL 3.3. Add several issues. 1 jbolz Internal revisions.