| Name |
| |
| EXT_sparse_texture2 |
| |
| Name Strings |
| |
| GL_EXT_sparse_texture2 |
| |
| Contact |
| |
| Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) |
| |
| Contributors |
| |
| Jeff Bolz, NVIDIA Corporation |
| Mathias Heyer, NVIDIA Corporation |
| Daniel Koch, NVIDIA Corporation |
| |
| Status |
| |
| Shipping |
| |
| Version |
| |
| Last Modified Date: April 19, 2016 |
| NVIDIA Revision: 3 |
| |
| Number |
| |
| OpenGL Extension #463 |
| OpenGL ES Extension #259 |
| |
| Dependencies |
| |
| This extension is written against the OpenGL 4.4 Specification |
| (Compatibility Profile), dated July 21, 2013. |
| |
| This extension is written against the OpenGL Shading Language |
| Specification, version 4.40, revision 6. |
| |
| When implemented in OpenGL, this extension requires and extends |
| ARB_sparse_texture. |
| |
| When implemented in OpenGL ES, this extension requires and extends |
| EXT_sparse_texture. |
| |
| This extension interacts trivially with EXT_depth_bounds_test. |
| |
| This extension interacts with NV_gpu_program4 and NV_gpu_program5. |
| |
| This extension interacts with OpenGL ES 3.1 (dated October 29th 2014). |
| |
| This extension interacts with OpenGL ES Shading Language 3.1 (revision 3). |
| |
| This extension interacts with EXT_gpu_shader5 and OES_gpu_shader5. |
| |
| This extension interacts with EXT_texture_norm16. |
| |
| This extension interacts with EXT_texture_cube_map_array and |
| OES_texture_cube_map_array. |
| |
| This extension interacts with OES_texture_storage_multisample_2D_array. |
| |
| |
| Overview |
| |
| This extension builds on the ARB_sparse_texture extension, providing the |
| following new functionality: |
| |
| * New built-in GLSL texture lookup and image load functions are provided |
| that return information on whether the texels accessed for the texture |
| lookup accessed uncommitted texture memory. |
| |
| * New built-in GLSL texture lookup functions are provided that specify a |
| minimum level of detail to use for lookups where the level of detail |
| is computed automatically. This allows shaders to avoid accessing |
| unpopulated portions of high-resolution levels of detail when it knows |
| that the memory accessed is unpopulated, either from a priori |
| knowledge or from feedback provided by the return value of previously |
| executed "sparse" texture lookup functions. |
| |
| * Reads of uncommitted texture memory will act as though such memory |
| were filled with zeroes; previously, the values returned by reads were |
| undefined. |
| |
| * Standard implementation-independent virtual page sizes for internal |
| formats required to be supported with sparse textures. These standard |
| sizes can be requested by leaving VIRTUAL_PAGE_SIZE_INDEX_ARB at its |
| initial value (0). |
| |
| * Support for creating sparse multisample and multisample array textures |
| is added. However, the virtual page sizes for such textures remain |
| fully implementation-dependent. |
| |
| New Procedures and Functions |
| |
| None. |
| |
| New Tokens |
| |
| None. |
| |
| Modifications to the OpenGL 4.4 Specification (Compatibility Profile) |
| |
| Modify Section 8.10, Texture Parameters, p. 250 |
| |
| (modify the following Errors section entry for TexParameter*, added by |
| ARB_sparse_texture, to allow for sparse multisample and multisample array |
| textures) |
| |
| INVALID_VALUE is generated if <pname> is TEXTURE_SPARSE_ARB, <pname> |
| is TRUE and <target> is not one of TEXTURE_2D, TEXTURE_2D_ARRAY, |
| TEXTURE_CUBE_MAP, TEXTURE_CUBE_MAP_ARRAY, TEXTURE_3D, TEXTURE_RECTANGLE, |
| TEXTURE_2D_MULTISAMPLE, or TEXTURE_2D_MULTISAMPLE_ARRAY. |
| |
| |
| Modify Section 8.14.1, Scale Factor and Level of Detail, p. 261 |
| |
| (move the next-to-last paragraph, p. 261, describing lod_min and lod_max |
| in equation 8.6, up one paragraph and modify it to read as follows) |
| |
| lod_min and lod_max indicate minimum and maximum clamps on the computed |
| level of detail. lod_max is taken directly from the TEXTURE_MAX_LOD |
| texture or sampler parameter. If a texture access is performed in a |
| fragment shader with a minimum level of detail clamp specified in the |
| built-in texture lookup function, lod_min is the larger of the |
| TEXTURE_MIN_LOD texture or sampler parameter and the minimum level of |
| detail provided by the shader. Otherwise, lod_min is taken directly from |
| the TEXTURE_MIN_LOD texture or sampler parameter. The initial values of |
| the TEXTURE_MIN_LOD and TEXTURE_MAX_LOD texture and sampler parameters are |
| chosen so as to never clamp the range of lambda values. |
| |
| |
| Modify the edits to Section 8.19 (Immutable-Format Texture Images), as |
| made by ARB_sparse_texture |
| |
| (remove the following language from the "p. 233" edits starting with "If |
| TEXTURE_SPARSE_ARB is TRUE"; there is no longer a restriction on the base |
| size of a sparse texture allocation) |
| |
| [REMOVED LANGUAGE] ... In this case, <width>, <height>, and <depth> must |
| either be integer multiples of the selected virtual page size in the X, Y, |
| and Z dimensions, respectively, or be less than those dimensions. ... |
| |
| (remove the following TexStorage error added by ARB_sparse_texture; there |
| is no longer a restriction on the base size of a sparse texture |
| allocation) |
| |
| [REMOVED LANGUAGE] An INVALID_VALUE error is generated if |
| TEXTURE_SPARSE_ARB is TRUE and <width>, <height> or <depth> is is not an |
| integer multiple of the page size in the corresponding dimension. |
| |
| (remove the error language beginning with "If the value of |
| SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS_ARB is FALSE", and replace with |
| the following) |
| |
| In older extensions supporting sparse textures, the constant |
| SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS_ARB was provided to advertise |
| implementation-dependent limitations potentially prohibiting the |
| allocation of array or cube map textures with full mipmap chains. No such |
| limitations apply in this extension. This constant is retained for |
| backwards compatibility, but all implementations of this extension must |
| return TRUE. |
| |
| |
| Modify Section 8.20.1 of ARB_sparse_texture (Allocation of and Access to |
| Sparse Textures) |
| |
| (insert after the two paragraphs discussing VIRTUAL_PAGE_SIZE_INDEX_ARB) |
| |
| When leaving the VIRTUAL_PAGE_SIZE_INDEX_ARB texture parameter at its |
| initial value (0), the virtual page size for many non-multisample sparse |
| textures can be found in Table 8.X. The virtual page size of such a |
| texture comes from the value listed in the "3D Page Size" column for the |
| texture target TEXTURE_3D, or the value listed in the "2D Page Size" |
| column for any other target. If the internal format of the texture is not |
| listed in Table 8.X or if the texture target is TEXTURE_2D_MULTISAMPLE or |
| TEXTURE_2D_MULTISAMPLE_ARRAY, the virtual page size for index zero is |
| fully implementation-dependent. |
| |
| Internal Format 2D Page Size 3D Page Size |
| --------------- ------------- ------------ |
| R8 256 x 256 x 1 64 x 32 x 32 |
| R8_SNORM |
| R8I |
| R8UI |
| |
| R16 256 x 128 x 1 32 x 32 x 32 |
| R16_SNORM |
| RG8 |
| RG8_SNORM |
| RGB565 |
| R16F |
| R16I |
| R16UI |
| RG8I |
| RG8UI |
| |
| RG16 128 x 128 x 1 32 x 32 x 16 |
| RG16_SNORM |
| RGBA8 |
| RGBA8_SNORM |
| RGB10_A2 |
| RGB10_A2UI |
| RG16F |
| R32F |
| R11F_G11F_B10F |
| RGB9_E5 |
| R32I |
| R32UI |
| RG16I |
| RG16UI |
| RGBA8I |
| RGBA8UI |
| |
| RGBA16 128 x 64 x 1 32 x 16 x 16 |
| RGBA16_SNORM |
| RGBA16F |
| RG32F |
| RG32I |
| RG32UI |
| RGBA16I |
| RGBA16UI |
| |
| RGBA32F 64 x 64 x 1 16 x 16 x 16 |
| RGBA32I |
| RGBA32UI |
| |
| Table 8.X, Standard Virtual Page Sizes for Sparse Textures |
| |
| |
| (modify first bullet under "When a sparsely committed texture is accessed |
| by the GL" at the end of the section) |
| |
| * Reads from such regions behave as if the data in texture memory for |
| all components present in the texture format were zero. This |
| includes samples required for the implementation of texture |
| filtering, image loads, mipmap generation, and so on. For texture |
| and image loads, components not present in the texture format (e.g., |
| alpha in a texture with an RGB base internal format) will return |
| default values, as in non-sparse textures. |
| |
| (modify third bullet under "When a sparsely committed texture is accessed |
| by the GL" at the end of the section) |
| |
| * Atomic operations operating on uncommitted regions will not generate |
| exceptions but will always return zero. The result of the atomic |
| operation, which is normally written to memory, will instead be |
| discarded. |
| |
| (add new bullets under "When a sparsely committed texture is accessed by |
| the GL" at the end of the section) |
| |
| * When performing the stencil test (section 17.3.5), depth buffer test |
| (section 17.3.6), or depth bounds test on pixels in uncommitted |
| regions, the results of the test will be consistent with reading a |
| value of zero from the framebuffer. No value is written to the |
| depth buffer. |
| |
| (add a new paragraph at the end of the section) |
| |
| The OpenGL Shading Language provides built-in functions that perform a |
| texture fetch or image load and return sparse texture status information |
| to the caller. The status information can be queried by the built-in |
| function sparseTexelsResidentEXT(), which returns false if the lookup |
| function read one or more uncommitted texels and true otherwise. For the |
| purposes of this query, texels addressed by a filter normally computing a |
| weighted average of multiple texels (e.g., LINEAR) will be considered to |
| access only those texels with non-zero weights. |
| |
| |
| Modify Section 8.20.2 of ARB_sparse_texture (Controlling Sparse Texture |
| Commitment) |
| |
| (modify the fifth paragraph of the section from ARB_sparse_texture, |
| starting with "For levels of a sparse texture where..." to guarantee that |
| any level greater than or equal to the page size in all dimensions can be |
| sparsely populated) |
| |
| For levels of a sparse texture where each dimension is greater than or |
| equal to of the virtual page size, the residency of individual page-size |
| regions is controlled by TexPageCommitmentARB and such levels may be |
| partially populated. When the mipmap chain reaches a level that is not |
| greater than or equal to the virtual page size in any dimension, padding |
| and memory layout considerations may make it impossible to treat that |
| level and subsequent smaller ones as partially populated. ... |
| |
| |
| Modifications to the OpenGL Shading Language Specification, Version 4.40 |
| |
| Including the following line in a shader can be used to control the |
| language features described in this extension: |
| |
| #extension GL_EXT_sparse_texture2 : <behavior> |
| |
| where <behavior> is as specified in section 3.3. |
| |
| New preprocessor #defines are added to the OpenGL Shading Language: |
| |
| #define GL_EXT_sparse_texture2 1 |
| |
| Modify Section 8.9, Texture Functions, p. 151 |
| |
| (insert after first paragraph, p. 152) |
| |
| The texture lookup functions with an <lodClamp> parameter specify a |
| minimum clamp applied to the automatic level of detail computations. |
| Since automatic level of detail calculations are only supported by |
| fragment shaders, these lookup functions are also only available in |
| fragment shaders. No functions with the <lodClamp> parameter are provided |
| for rectangle textures, multisample textures, and texture buffers because |
| mipmaps are not allowed for these types of textures. |
| |
| |
| Modify Section 8.9.2, Texel Lookup Functions, p. 155 |
| |
| (This extension adds two new variants of texture lookup functions. The |
| "sparse" functions are like normal texture lookup functions, except that |
| they return a sparse texture residency status to the caller and return the |
| actual filtered texel value in an "out" parameter. The "Clamp" variants |
| are functions adding a new parameter specifying a minimum LOD to use for |
| texture lookup functions where level of detail is computed automatically. |
| |
| For each set of texture functions, we provide one to three new variants |
| based on whether sparse and LOD clamping functionality are desired. These |
| new variants copy the existing functions, add suffixes to the function |
| names, and add one or more new parameters. |
| |
| We create new variants only for the targets for which sparse storage is |
| supported -- no new functions are added for the following sampler types: |
| gsampler1D, sampler1DShadow, gsampler1DArray, sampler1DArrayShadow. |
| Additionally, to reduce the number of new functions added, we are not |
| including any new variants for textureProj*() built-ins. To use the new |
| features with projective texture lookups, shaders can divide through by q |
| and use non-projective variants. We also chose not to provide "Clamp" |
| variants of functions like textureLod() expecting an explicit |
| level-of-detail.) |
| |
| (insert new lookup function table cells, at the end of the section, |
| p. 161) |
| |
| Syntax: |
| |
| int sparseTextureEXT(gsampler2D sampler, vec2 P, |
| out gvec4 texel [, float bias]); |
| int sparseTextureEXT(gsampler3D sampler, vec3 P, |
| out gvec4 texel [, float bias]); |
| int sparseTextureEXT(gsamplerCube sampler, vec3 P, |
| out gvec4 texel [, float bias]); |
| int sparseTextureEXT(sampler2DShadow sampler, vec3 P, |
| out float texel [, float bias]); |
| int sparseTextureEXT(samplerCubeShadow sampler, vec4 P, |
| out float texel [, float bias]); |
| int sparseTextureEXT(gsampler2DArray sampler, vec3 P, |
| out gvec4 texel [, float bias]); |
| int sparseTextureEXT(gsamplerCubeArray sampler, vec4 P, |
| out gvec4 texel [, float bias]); |
| int sparseTextureEXT(sampler2DArrayShadow sampler, vec4 P, |
| out float texel); |
| int sparseTextureEXT(gsampler2DRect sampler, vec2 P, |
| out gvec4 texel); |
| int sparseTextureEXT(sampler2DRectShadow sampler, vec3 P, |
| out float texel); |
| int sparseTextureEXT(samplerCubeArrayShadow sampler, vec4 P, |
| float compare, out float texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in texture(), but return texture access |
| residency information from the function and the filtered lookup result in |
| the out parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureClampEXT(gsampler2D sampler, vec2 P, |
| float lodClamp, out gvec4 texel |
| [, float bias]); |
| int sparseTextureClampEXT(gsampler3D sampler, vec3 P, |
| float lodClamp, out gvec4 texel |
| [, float bias]); |
| int sparseTextureClampEXT(gsamplerCube sampler, vec3 P, |
| float lodClamp, out gvec4 texel |
| [, float bias]); |
| int sparseTextureClampEXT(sampler2DShadow sampler, vec3 P, |
| float lodClamp, out float texel |
| [, float bias]); |
| int sparseTextureClampEXT(samplerCubeShadow sampler, vec4 P, |
| float lodClamp, out float texel |
| [, float bias]); |
| int sparseTextureClampEXT(gsampler2DArray sampler, vec3 P, |
| float lodClamp, out gvec4 texel |
| [, float bias]); |
| int sparseTextureClampEXT(gsamplerCubeArray sampler, vec4 P, |
| float lodClamp, out gvec4 texel |
| [, float bias]); |
| int sparseTextureClampEXT(sampler2DArrayShadow sampler, vec4 P, |
| float lodClamp, out float texel); |
| int sparseTextureClampEXT(samplerCubeArrayShadow sampler, vec4 P, |
| float compare, float lodClamp, |
| out float texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in texture(), but return texture access |
| residency information from the function and the filtered lookup result in |
| the out parameter <texel>. Additionally, clamp the automatically computed |
| level of detail to be greater than or equal to <lodClamp>. |
| |
| -- |
| |
| Syntax: |
| |
| gvec4 textureClampEXT(gsampler1D sampler, float P, |
| float lodClamp [, float bias]); |
| gvec4 textureClampEXT(gsampler2D sampler, vec2 P, |
| float lodClamp [, float bias]); |
| gvec4 textureClampEXT(gsampler3D sampler, vec3 P, |
| float lodClamp [, float bias]); |
| gvec4 textureClampEXT(gsamplerCube sampler, vec3 P, |
| float lodClamp [, float bias]); |
| float textureClampEXT(sampler1DShadow sampler, vec3 P, |
| float lodClamp [, float bias]); |
| float textureClampEXT(sampler2DShadow sampler, vec3 P, |
| float lodClamp [, float bias]); |
| float textureClampEXT(samplerCubeShadow sampler, vec4 P, |
| float lodClamp [, float bias]); |
| gvec4 textureClampEXT(gsampler1DArray sampler, vec2 P, |
| float lodClamp [, float bias]); |
| gvec4 textureClampEXT(gsampler2DArray sampler, vec3 P, |
| float lodClamp [, float bias]); |
| gvec4 textureClampEXT(gsamplerCubeArray sampler, vec4 P, |
| float lodClamp [, float bias]); |
| float textureClampEXT(sampler1DArrayShadow sampler, vec3 P, |
| float lodClamp [, float bias]); |
| float textureClampEXT(sampler2DArrayShadow sampler, vec4 P, |
| float lodClamp); |
| float textureClampEXT(samplerCubeArrayShadow sampler, vec4 P, |
| float compare, float lodClamp); |
| |
| Description: |
| |
| Do a filtered texture lookup as in texture(), but clamp the automatically |
| computed level of detail to be greater than or equal to <lodClamp>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureLodEXT(gsampler2D sampler, vec2 P, float lod, |
| out gvec4 texel); |
| int sparseTextureLodEXT(gsampler3D sampler, vec3 P, float lod, |
| out gvec4 texel); |
| int sparseTextureLodEXT(gsamplerCube sampler, vec3 P, float lod, |
| out gvec4 texel); |
| int sparseTextureLodEXT(sampler2DShadow sampler, vec3 P, float lod, |
| out float texel); |
| int sparseTextureLodEXT(gsampler2DArray sampler, vec3 P, float lod, |
| out gvec4 texel); |
| int sparseTextureLodEXT(gsamplerCubeArray sampler, vec4 P, float lod, |
| out gvec4 texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureLod(), but return texture access |
| residency information from the function and the filtered lookup result in |
| the out parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureOffsetEXT(gsampler2D sampler, vec2 P, |
| ivec2 offset, out gvec4 texel |
| [, float bias]); |
| int sparseTextureOffsetEXT(gsampler3D sampler, vec3 P, |
| ivec3 offset, out gvec4 texel |
| [, float bias]); |
| int sparseTextureOffsetEXT(gsampler2DRect sampler, vec2 P, |
| ivec2 offset, out gvec4 texel); |
| int sparseTextureOffsetEXT(sampler2DRectShadow sampler, vec3 P, |
| ivec2 offset, out float texel); |
| int sparseTextureOffsetEXT(sampler2DShadow sampler, vec3 P, |
| ivec2 offset, out float texel |
| [, float bias]); |
| int sparseTextureOffsetEXT(gsampler2DArray sampler, vec3 P, |
| ivec2 offset, out gvec4 texel |
| [, float bias]); |
| int sparseTextureOffsetEXT(sampler2DArrayShadow sampler, vec4 P, |
| ivec2 offset, out float texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureOffset(), but return texture |
| access residency information from the function and the filtered lookup |
| result in the out parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureOffsetClampEXT(gsampler2D sampler, vec2 P, |
| ivec2 offset, float lodClamp, |
| out gvec4 texel [, float bias]); |
| int sparseTextureOffsetClampEXT(gsampler3D sampler, vec3 P, |
| ivec3 offset, float lodClamp, |
| out gvec4 texel [, float bias]); |
| int sparseTextureOffsetClampEXT(sampler2DShadow sampler, vec3 P, |
| ivec2 offset, float lodClamp, |
| out float texel [, float bias]); |
| int sparseTextureOffsetClampEXT(gsampler2DArray sampler, vec3 P, |
| ivec2 offset, float lodClamp, |
| out gvec4 texel [, float bias]); |
| int sparseTextureOffsetClampEXT(sampler2DArrayShadow sampler, vec4 P, |
| ivec2 offset, float lodClamp, |
| out float texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureOffset(), but return texture |
| access residency information from the function and the filtered lookup |
| result in the out parameter <texel>. Additionally, clamp the |
| automatically computed level of detail to be greater than or equal to |
| <lodClamp>. |
| |
| -- |
| |
| Syntax: |
| |
| gvec4 textureOffsetClampEXT(gsampler1D sampler, float P, |
| int offset, float lodClamp [, float bias]); |
| gvec4 textureOffsetClampEXT(gsampler2D sampler, vec2 P, |
| ivec2 offset, float lodClamp [, float bias]); |
| gvec4 textureOffsetClampEXT(gsampler3D sampler, vec3 P, |
| ivec3 offset, float lodClamp [, float bias]); |
| float textureOffsetClampEXT(sampler1DShadow sampler, vec3 P, |
| int offset, float lodClamp [, float bias]); |
| float textureOffsetClampEXT(sampler2DShadow sampler, vec3 P, |
| ivec2 offset, float lodClamp [, float bias]); |
| gvec4 textureOffsetClampEXT(gsampler1DArray sampler, vec2 P, |
| int offset, float lodClamp [, float bias]); |
| gvec4 textureOffsetClampEXT(gsampler2DArray sampler, vec3 P, |
| ivec2 offset, float lodClamp [, float bias]); |
| float textureOffsetClampEXT(sampler1DArrayShadow sampler, vec3 P, |
| int offset, float lodClamp [, float bias]); |
| float textureOffsetClampEXT(sampler2DArrayShadow sampler, vec4 P, |
| ivec2 offset, float lodClamp); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureOffset(), but clamp the |
| automatically computed level of detail to be greater than or equal to |
| <lodClamp>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTexelFetchEXT(gsampler2D sampler, ivec2 P, int lod, |
| out gvec4 texel); |
| int sparseTexelFetchEXT(gsampler3D sampler, ivec3 P, int lod, |
| out gvec4 texel); |
| int sparseTexelFetchEXT(gsampler2DRect sampler, ivec2 P, |
| out gvec4 texel); |
| int sparseTexelFetchEXT(gsampler2DArray sampler, ivec3 P, int lod, |
| out gvec4 texel); |
| int sparseTexelFetchEXT(gsampler2DMS sampler, ivec2 P, int sample, |
| out gvec4 texel); |
| int sparseTexelFetchEXT(gsampler2DMSArray sampler, ivec3 P, int sample, |
| out gvec4 texel); |
| |
| Description: |
| |
| Do a single texel fetch as in texelFetch(), but return texture access |
| residency information from the function and the fetched texel in the out |
| parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTexelFetchOffsetEXT(gsampler2D sampler, ivec2 P, int lod, |
| ivec2 offset, out gvec4 texel); |
| int sparseTexelFetchOffsetEXT(gsampler3D sampler, ivec3 P, int lod, |
| ivec3 offset, out gvec4 texel); |
| int sparseTexelFetchOffsetEXT(gsampler2DRect sampler, ivec2 P, |
| ivec2 offset, out gvec4 texel); |
| int sparseTexelFetchOffsetEXT(gsampler2DArray sampler, ivec3 P, int lod, |
| ivec2 offset, out gvec4 texel); |
| |
| Description: |
| |
| Do a single texel fetch as in texelFetchOffset(), but return texture |
| access residency information from the function and the fetched texel in |
| the out parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureLodOffsetEXT(gsampler2D sampler, vec2 P, |
| float lod, ivec2 offset, |
| out gvec4 texel); |
| int sparseTextureLodOffsetEXT(gsampler3D sampler, vec3 P, |
| float lod, ivec3 offset, |
| out gvec4 texel); |
| int sparseTextureLodOffsetEXT(sampler2DShadow sampler, vec3 P, |
| float lod, ivec2 offset, |
| out float texel); |
| int sparseTextureLodOffsetEXT(gsampler2DArray sampler, vec3 P, |
| float lod, ivec2 offset, |
| out gvec4 texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureLodOffset(), but return texture |
| access residency information from the function and the filtered lookup |
| result in the out parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureGradEXT(gsampler2D sampler, vec2 P, |
| vec2 dPdx, vec2 dPdy, |
| out gvec4 texel); |
| int sparseTextureGradEXT(gsampler3D sampler, vec3 P, |
| vec3 dPdx, vec3 dPdy, |
| out gvec4 texel); |
| int sparseTextureGradEXT(gsamplerCube sampler, vec3 P, |
| vec3 dPdx, vec3 dPdy, |
| out gvec4 texel); |
| int sparseTextureGradEXT(gsampler2DRect sampler, vec2 P, |
| vec2 dPdx, vec2 dPdy, |
| out gvec4 texel); |
| int sparseTextureGradEXT(sampler2DRectShadow sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, |
| out float texel); |
| int sparseTextureGradEXT(sampler2DShadow sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, |
| out float texel); |
| int sparseTextureGradEXT(samplerCubeShadow sampler, vec4 P, |
| vec3 dPdx, vec3 dPdy, |
| out float texel); |
| int sparseTextureGradEXT(gsampler2DArray sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, |
| out gvec4 texel); |
| int sparseTextureGradEXT(sampler2DArrayShadow sampler, vec4 P, |
| vec2 dPdx, vec2 dPdy, |
| out float texel); |
| int sparseTextureGradEXT(gsamplerCubeArray sampler, vec4 P, |
| vec3 dPdx, vec3 dPdy, |
| out gvec4 texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureGrad(), but return texture |
| access residency information from the function and the filtered lookup |
| result in the out parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureGradClampEXT(gsampler2D sampler, vec2 P, |
| vec2 dPdx, vec2 dPdy, float lodClamp, |
| out gvec4 texel); |
| int sparseTextureGradClampEXT(gsampler3D sampler, vec3 P, |
| vec3 dPdx, vec3 dPdy, float lodClamp, |
| out gvec4 texel); |
| int sparseTextureGradClampEXT(gsamplerCube sampler, vec3 P, |
| vec3 dPdx, vec3 dPdy, float lodClamp, |
| out gvec4 texel); |
| int sparseTextureGradClampEXT(sampler2DShadow sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, float lodClamp, |
| out float texel); |
| int sparseTextureGradClampEXT(samplerCubeShadow sampler, vec4 P, |
| vec3 dPdx, vec3 dPdy, float lodClamp, |
| out float texel); |
| int sparseTextureGradClampEXT(gsampler2DArray sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, float lodClamp, |
| out gvec4 texel); |
| int sparseTextureGradClampEXT(sampler2DArrayShadow sampler, vec4 P, |
| vec2 dPdx, vec2 dPdy, float lodClamp, |
| out float texel); |
| int sparseTextureGradClampEXT(gsamplerCubeArray sampler, vec4 P, |
| vec3 dPdx, vec3 dPdy, float lodClamp, |
| out gvec4 texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureGrad(), but return texture |
| access residency information from the function and the filtered lookup |
| result in the out parameter <texel>. Additionally, clamp the |
| automatically computed level of detail to be greater than or equal to |
| <lodClamp>. |
| |
| -- |
| |
| Syntax: |
| |
| gvec4 textureGradClampEXT(gsampler1D sampler, float P, |
| float dPdx, float dPdy, float lodClamp); |
| gvec4 textureGradClampEXT(gsampler2D sampler, vec2 P, |
| vec2 dPdx, vec2 dPdy, float lodClamp); |
| gvec4 textureGradClampEXT(gsampler3D sampler, vec3 P, |
| vec3 dPdx, vec3 dPdy, float lodClamp); |
| gvec4 textureGradClampEXT(gsamplerCube sampler, vec3 P, |
| vec3 dPdx, vec3 dPdy, float lodClamp); |
| float textureGradClampEXT(sampler1DShadow sampler, vec3 P, |
| float dPdx, float dPdy, float lodClamp); |
| float textureGradClampEXT(sampler2DShadow sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, float lodClamp); |
| float textureGradClampEXT(samplerCubeShadow sampler, vec4 P, |
| vec3 dPdx, vec3 dPdy, float lodClamp); |
| gvec4 textureGradClampEXT(gsampler1DArray sampler, vec2 P, |
| float dPdx, float dPdy, float lodClamp); |
| gvec4 textureGradClampEXT(gsampler2DArray sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, float lodClamp); |
| float textureGradClampEXT(sampler1DArrayShadow sampler, vec3 P, |
| float dPdx, float dPdy, float lodClamp); |
| float textureGradClampEXT(sampler2DArrayShadow sampler, vec4 P, |
| vec2 dPdx, vec2 dPdy, float lodClamp); |
| gvec4 textureGradClampEXT(gsamplerCubeArray sampler, vec4 P, |
| vec3 dPdx, vec3 dPdy, float lodClamp); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureGrad(), but clamp the |
| automatically computed level of detail to be greater than or equal to |
| <lodClamp>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureGradOffsetEXT(gsampler2D sampler, vec2 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| out gvec4 texel); |
| int sparseTextureGradOffsetEXT(gsampler3D sampler, vec3 P, |
| vec3 dPdx, vec3 dPdy, ivec3 offset, |
| out gvec4 texel); |
| int sparseTextureGradOffsetEXT(gsampler2DRect sampler, vec2 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| out gvec4 texel); |
| int sparseTextureGradOffsetEXT(sampler2DRectShadow sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| out float texel); |
| int sparseTextureGradOffsetEXT(sampler2DShadow sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| out float texel); |
| int sparseTextureGradOffsetEXT(gsampler2DArray sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| out gvec4 texel); |
| int sparseTextureGradOffsetEXT(sampler2DArrayShadow sampler, vec4 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| out float texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureGradOffset(), but return texture |
| access residency information from the function and the filtered lookup |
| result in the out parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureGradOffsetClampEXT(gsampler2D sampler, vec2 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| float lodClamp, out gvec4 texel); |
| int sparseTextureGradOffsetClampEXT(gsampler3D sampler, vec3 P, |
| vec3 dPdx, vec3 dPdy, ivec3 offset, |
| float lodClamp, out gvec4 texel); |
| int sparseTextureGradOffsetClampEXT(sampler2DShadow sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| float lodClamp, out float texel); |
| int sparseTextureGradOffsetClampEXT(gsampler2DArray sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| float lodClamp, out gvec4 texel); |
| int sparseTextureGradOffsetClampEXT(sampler2DArrayShadow sampler, vec4 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| float lodClamp, out float texel); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureGradOffset(), but return texture |
| access residency information from the function and the filtered lookup |
| result in the out parameter <texel>. Additionally, clamp the |
| automatically computed level of detail to be greater than or equal to |
| <lodClamp>. |
| |
| -- |
| |
| Syntax: |
| |
| gvec4 textureGradOffsetClampEXT(gsampler1D sampler, float P, |
| float dPdx, float dPdy, int offset, |
| float lodClamp); |
| gvec4 textureGradOffsetClampEXT(gsampler2D sampler, vec2 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| float lodClamp); |
| gvec4 textureGradOffsetClampEXT(gsampler3D sampler, vec3 P, |
| vec3 dPdx, vec3 dPdy, ivec3 offset, |
| float lodClamp); |
| float textureGradOffsetClampEXT(sampler1DShadow sampler, vec3 P, |
| float dPdx, float dPdy, int offset, |
| float lodClamp); |
| float textureGradOffsetClampEXT(sampler2DShadow sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| float lodClamp); |
| gvec4 textureGradOffsetClampEXT(gsampler1DArray sampler, vec2 P, |
| float dPdx, float dPdy, int offset, |
| float lodClamp); |
| gvec4 textureGradOffsetClampEXT(gsampler2DArray sampler, vec3 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| float lodClamp); |
| float textureGradOffsetClampEXT(sampler1DArrayShadow sampler, vec3 P, |
| float dPdx, float dPdy, int offset, |
| float lodClamp); |
| float textureGradOffsetClampEXT(sampler2DArrayShadow sampler, vec4 P, |
| vec2 dPdx, vec2 dPdy, ivec2 offset, |
| float lodClamp); |
| |
| Description: |
| |
| Do a filtered texture lookup as in textureGrad(), but clamp the |
| automatically computed level of detail to be greater than or equal to |
| <lodClamp>. |
| |
| |
| Modify Section 8.9.3, Texel Gather Functions, p. 161 |
| |
| (insert new lookup function table cells, at the end of the section, |
| p. 163) |
| |
| Syntax: |
| |
| int sparseTextureGatherEXT(gsampler2D sampler, vec2 P, |
| out gvec4 texel [, int comp]); |
| int sparseTextureGatherEXT(gsampler2DArray sampler, vec3 P, |
| out gvec4 texel [, int comp]); |
| int sparseTextureGatherEXT(gsamplerCube sampler, vec3 P, |
| out gvec4 texel [, int comp]); |
| int sparseTextureGatherEXT(gsamplerCubeArray sampler, vec4 P, |
| out gvec4 texel [, int comp]); |
| int sparseTextureGatherEXT(gsampler2DRect sampler, vec2 P, |
| out gvec4 texel [, int comp]); |
| int sparseTextureGatherEXT(gsampler2DShadow sampler, vec2 P, |
| float refZ, out vec4 texel); |
| int sparseTextureGatherEXT(gsampler2DArrayShadow sampler, vec3 P, |
| float refZ, out vec4 texel); |
| int sparseTextureGatherEXT(gsamplerCubeShadow sampler, vec3 P, |
| float refZ, out vec4 texel); |
| int sparseTextureGatherEXT(gsamplerCubeArrayShadow sampler, vec4 P, |
| float refZ, out vec4 texel); |
| int sparseTextureGatherEXT(gsampler2DRectShadow sampler, vec2 P, |
| float refZ, out vec4 texel); |
| |
| Description: |
| |
| Do a texture gather operation as in textureGather(), but return texture |
| access residency information from the function and the filtered lookup |
| result in the out parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureGatherOffsetEXT(gsampler2D sampler, vec2 P, |
| ivec2 offset, out gvec4 texel |
| [, int comp]); |
| int sparseTextureGatherOffsetEXT(gsampler2DArray sampler, vec3 P, |
| ivec2 offset, out gvec4 texel |
| [, int comp]); |
| int sparseTextureGatherOffsetEXT(gsampler2DRect sampler, vec2 P, |
| ivec2 offset, out gvec4 texel |
| [, int comp]); |
| int sparseTextureGatherOffsetEXT(gsampler2DShadow sampler, vec2 P, |
| float refZ, ivec2 offset, |
| out vec4 texel); |
| int sparseTextureGatherOffsetEXT(gsampler2DArrayShadow sampler, vec3 P, |
| float refZ, ivec2 offset, |
| out vec4 texel); |
| int sparseTextureGatherOffsetEXT(gsampler2DRectShadow sampler, vec2 P, |
| float refZ, ivec2 offset, |
| out vec4 texel); |
| |
| Description: |
| |
| Do a texture gather operation as in textureGatherOffset(), but return |
| texture access residency information from the function and the filtered |
| lookup result in the out parameter <texel>. |
| |
| -- |
| |
| Syntax: |
| |
| int sparseTextureGatherOffsetsEXT(gsampler2D sampler, vec2 P, |
| ivec2 offsets[4], out gvec4 texel |
| [, int comp]); |
| int sparseTextureGatherOffsetsEXT(gsampler2DArray sampler, vec3 P, |
| ivec2 offsets[4], out gvec4 texel |
| [, int comp]); |
| int sparseTextureGatherOffsetsEXT(gsampler2DRect sampler, vec2 P, |
| ivec2 offsets[4], out gvec4 texel |
| [, int comp]); |
| int sparseTextureGatherOffsetsEXT(gsampler2DShadow sampler, vec2 P, |
| float refZ, ivec2 offsets[4], |
| out vec4 texel); |
| int sparseTextureGatherOffsetsEXT(gsampler2DArrayShadow sampler, vec3 P, |
| float refZ, ivec2 offsets[4], |
| out vec4 texel); |
| int sparseTextureGatherOffsetsEXT(gsampler2DRectShadow sampler, vec2 P, |
| float refZ, ivec2 offsets[4], |
| out vec4 texel); |
| |
| Description: |
| |
| Do a texture gather operation as in textureGatherOffset(), but return |
| texture access residency information from the function and the filtered |
| lookup result in the out parameter <texel>. |
| |
| |
| Add to the end of Section 8.12, Image Functions, p. 167 |
| |
| (insert new lookup function table cells, at the end of the section, |
| p. 170) |
| |
| Syntax: |
| |
| int sparseImageLoadEXT(gimage2D image, ivec2 P, |
| out gvec4 texel); |
| int sparseImageLoadEXT(gimage3D image, ivec3 P, |
| out gvec4 texel); |
| int sparseImageLoadEXT(gimage2DRect image, ivec2 P, |
| out gvec4 texel); |
| int sparseImageLoadEXT(gimageCube image, ivec3 P, |
| out gvec4 texel); |
| int sparseImageLoadEXT(gimage2DArray image, ivec3 P, |
| out gvec4 texel); |
| int sparseImageLoadEXT(gimageCubeArray image, ivec3 P, |
| out gvec4 texel); |
| int sparseImageLoadEXT(gimage2DMS image, ivec2 P, int sample, |
| out gvec4 texel); |
| int sparseImageLoadEXT(gimage2DMSArray image, ivec3 P, int sample, |
| out gvec4 texel); |
| |
| Description: |
| |
| Loads a texel from the image <image> as in imageLoad(), but return texture |
| access residency information from the function and the filtered lookup |
| result in the out parameter <texel>. |
| |
| |
| Add to the end of Section 8.17, Shader Memory Control Functions, p. 178 |
| |
| Many of the built-in texture lookup functions in sections 8.9.2 and 8.9.3 |
| and the sparseImageLoad() function in section 8.12 can be used to return |
| sparse texture residency information in addition to texel values. In |
| these functions, the sparse texture residency information is returned by |
| the function as an integer and the texel values are returned in the output |
| parameter <texel>. The residency information can be interpreted by a |
| built-in function to determine if the lookup accessed any uncommitted |
| texels. |
| |
| Syntax: |
| |
| bool sparseTexelsResidentEXT(int code); |
| |
| Description: |
| |
| Returns false if any of the texels accessed by the sparse texture lookup |
| generating <code> were in uncommitted texture memory, and true |
| otherwise. |
| |
| |
| Additions to the AGL/GLX/WGL Specifications |
| |
| None. |
| |
| Errors |
| |
| None. |
| |
| New State |
| |
| None. |
| |
| New Implementation Dependent State |
| |
| None. |
| |
| Dependencies on OpenGL ES 3.1 |
| |
| Replace references to ARB_sparse_texture with references to |
| EXT_sparse_texture, in particular functions and enums introduced by |
| EXT_sparse_texture will carry EXT suffixes. |
| |
| If implemented on OpenGL ES 3.1, remove all references to 1D and |
| rectangle textures and their respective texture targets (TEXTURE_1D |
| and TEXTURE_RECTANGLE). Also ignore the corresponding sampler |
| built-ins thereof: 'gsampler1D', 'gsampler2DRect' and |
| 'gsampler2DRectShadow'. Do not introduce overloads of |
| sparseTexture*EXT, texture*ClampEXT or sparseTexelFetchEXT for these |
| sampler types. |
| |
| Do not introduce sparseImageLoadEXT overloads of gimageRect, |
| gimage2D, gimage2DArray, gimage2DMS and gimage2DArrayMS. |
| |
| Dependencies on EXT_texture_norm16 |
| |
| If implemented on OpenGL ES 3.1 and EXT_texture_norm16 is not |
| supported ignore all references to R16, RG16, RGBA16, R16_SNORM, |
| RG16_SNORM and RGBA16_SNORM. If EXT_texture_norm16 is supported, |
| these enums are suffixed by _EXT. |
| |
| Dependencies on EXT_texture_cube_map_array and OES_texture_cube_map_array |
| |
| If implemented on OpenGL ES 3.1 and neither EXT_texture_cube_map_array |
| nor OES_texture_cube_map_array is supported, ignore all references to |
| texture sampler types 'gsamplerCubeArray' and 'gsamplerCubeArrayShadow'. |
| Do not introduce overloads of sparseTexture*EXT, texture*ClampEXT or |
| sparseTexelFetchEXT for these sampler types. Remove references to |
| TEXTURE_CUBE_MAP_ARRAY. |
| |
| Dependencies on OES_texture_storage_multisample_2D_array |
| |
| If implemented on OpenGL ES 3.1 and OES_texture_storage_- |
| multisample_2D_array is not supported, ignore all references to |
| texture sampler types 'gsampler2DMS' and 'gsampler2DMSArray'. Do not |
| introduce overloads of sparseTexture*EXT, texture*ClampEXT or |
| sparseTexelFetchEXT for these sampler types. Remove references to |
| TEXTURE_2D_MULTISAMPLE_ARRAY. |
| |
| Dependencies on EXT_gpu_shader5 and OES_gpu_shader5 |
| |
| If implemented on OpenGL GLSL ES 3.1 and neither EXT_gpu_shader5 nor |
| OES_gpu_shader5 is supported, do not introduce |
| sparseTextureGatherOffsetsEXT. |
| |
| 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 NV_gpu_program4 and NV_gpu_program5 |
| |
| Modify Section 2.X.2, Program Grammar |
| |
| <opModifier> ::= "SPARSE" |
| | "LODCLAMP" |
| |
| <ccMaskRule> ::= "RESIDENT" |
| | "NONRESIDENT" |
| |
| Modify Section 2.X.3.7, Program Condition Code Registers |
| |
| (modify the first paragraph) |
| |
| There are two general-purpose four-component condition code registers (CC0 |
| and CC1), where each component of this register is a collection of |
| single-bit flags, including a sign flag (SF), a zero flag (ZF), an |
| overflow flag (OF), and a carry flag (CF). The values of these registers |
| are undefined at the beginning of program execution. Additionally, there |
| is a special single-component sparse memory condition code register that |
| holds the status of the most recently executed texture or image load |
| instruction using the "SPARSE" opcode modifier. This condition code |
| includes a resident flag (RESF) indicating whether all memory accessed by |
| the instruction was populated. |
| |
| Modify Section 2.X.4.1, Program Instruction Modifiers |
| |
| (Update the discussion of instruction precision modifiers. If |
| GL_NV_gpu_program_fp64 is not found in the extension string, the "F64" |
| instruction modifier described below is not supported.) |
| |
| (add to Table X.14 of the NV_gpu_program4 specification.) |
| |
| Modifier Description |
| -------- ------------------------------------------------------ |
| SPARSE Update the sparse memory condition code with status on |
| whether the memory accessed by a texture or image load |
| instruction was fully populated. |
| |
| LODCLAMP Clamp the LOD used by texture lookups to a specified |
| value |
| |
| For texture fetch, surface load, and surface atomic instructions, the |
| "SPARSE" modifier specifies that the sparse memory condition code |
| described in Section 2.X.3.7 should be updated to reflect whether the |
| memory accessed by the instruction was fully populated. |
| |
| For texture fetch instructions with implicit LOD calcuations (TEX, TXB, |
| TXD), the "LODCLAMP" modifier specifies that the instruction includes an |
| extra floating-point component indicating a minimum level of detail to be |
| used for the texture lookup. If the implicitly computed level of detail |
| is less than the level of detail provided in the instruction data, that |
| level should be used instead. |
| |
| Modify Section 2.X.4.3, Program Destination Variable Update |
| |
| (add to Table X.16, Condition Code Tests) |
| |
| mask rule test name condition |
| --------------- ---------------------- ----------------- |
| RESIDENT sparse resident RESF |
| NONRESIDENT sparse nonresident !RESF |
| |
| (also modify the table description) |
| |
| Table X.16, Condition Code Tests. The allowed rules are specified in |
| the "mask rule" column. For "RESIDENT" or "NONRESIDENT", all four |
| components of the test result are loaded from the RESF flag of the |
| sparse condition code. Otherwise, If "0" or "1" is appended ... |
| |
| (modify the paragraph about condition code updates) |
| |
| A program instruction can also optionally update one of the two general |
| condition code registers ... |
| |
| (add a new paragraph about updating CCSPARSE) |
| |
| Additionally, a program instruction accessing memory can optionally update |
| the sparse memory condition code register if the "SPARSE" instruction |
| modifier is specified. If the memory accessed by the instruction was |
| fully populated, the resident flag (RESF) is set; otherwise, RESF is |
| cleared. |
| |
| Modify Section 2.X.4.4, Program Texture Access |
| |
| (modify the prototype of the TextureSample utility function, adding |
| <coord2> and removing <lod>) |
| |
| result_t_vec |
| TextureSample(float_vec coord, float_vec coord2, |
| float_vec ddx, float_vec ddy, int_vec offset); |
| |
| (modify the description of <coord> to add <coord2>) |
| |
| <coord> and <coord2> are two four-component floating-point vectors from |
| which the (s,t,r) texture coordinates used for the texture access, the |
| layer used for array textures, and the reference value used for depth |
| comparisons (section 3.8.14) are extracted according to Table X.17. ... |
| |
| (replace the paragraph discussing <lod>) |
| |
| <ddx> and <ddy> specify partial derivatives (ds/dx, dt/dx, dr/dx, ds/dy, |
| dt/dy, and dr/dy) for the texture coordinates, and may be used for level |
| of detail calculations and to derive footprint shapes for anisotropic |
| texture filtering. |
| |
| The level of detail used for the texture lookup is a function of the |
| texture instruction type, texture target, LODCLAMP qualifier, and the |
| inputs <ddx> and <ddy>. For TEX, TXB, TXD, and TXP instructions in a base |
| level of detail is computed based on the partial derivatives <ddx> and |
| <ddy>. For the TXB and TXL instruction, an additional level of detail |
| value is taken from the component in <coord> or <coord2> identified by the |
| first entry in the "lod" column of Table X.17. For TXB, this value is |
| added to the computed base level of detail; for TXL, it specifies the base |
| level of detail. After that, per-texture and per-texture unit LOD biases |
| are added to the level of detail. Finally, if the LODCLAMP opcode |
| modifier is specified, an LOD clamp value is extracted from <coord> or |
| <coord2> according to the second entry in the "lod" column of Table X.17. |
| The computed level of detail is clamped to be greater than or equal to |
| this LOD clamp value. |
| |
| coordinates used |
| texTarget Texture Type s t r lay shd lod |
| ---------------- --------------------- ----- --- --- ----- |
| 1D TEXTURE_1D x - - - - w,x2 |
| 2D TEXTURE_2D x y - - - w,x2 |
| 3D TEXTURE_3D x y z - - w,x2 |
| CUBE TEXTURE_CUBE_MAP x y z - - w,x2 |
| RECT TEXTURE_RECTANGLE_ARB x y - - - -,- |
| ARRAY1D TEXTURE_1D_ARRAY_EXT x - - y - w,x2 |
| ARRAY2D TEXTURE_2D_ARRAY_EXT x y - z - w,x2 |
| ARRAYCUBE TEXTURE_CUBE_MAP_ARRAY x y z w - x2,y2 |
| SHADOW1D TEXTURE_1D x - - - z w,x2 |
| SHADOW2D TEXTURE_2D x y - - z w,x2 |
| SHADOWRECT TEXTURE_RECTANGLE_ARB x y - - z -,- |
| SHADOWCUBE TEXTURE_CUBE_MAP x y z - w x2,y2 |
| SHADOWARRAY1D TEXTURE_1D_ARRAY_EXT x - - y z w,x2 |
| SHADOWARRAY2D TEXTURE_2D_ARRAY_EXT x y - z w -,x2 |
| SHADOWARRAYCUBE TEXTURE_CUBE_MAP_ARRAY x y z w x2 -,y2 |
| BUFFER TEXTURE_BUFFER_EXT <not supported> |
| RENDERBUFFER TEXTURE_RENDERBUFFER <not supported> |
| 2DMS TEXTURE_2D_MULTISAMPLE <not supported> |
| ARRAY2DMS TEXTURE_2D_MULTISAMPLE_ <not supported> |
| ARRAY |
| |
| Table X.17: Texture types accessed for each of the <texTarget>, and |
| coordinate mappings. Components "x", "y", "z", and "w" are taken from |
| the first coordinate vector <coord>; "x2" and "y2" are taken from the |
| second vector <coord2>. The "SHADOW" and "ARRAY" targets are special |
| pseudo-targets described below. The "coordinates used" column indicate |
| the input values used for each coordinate of the texture lookup, the |
| layer selector for array textures, the reference value for texture |
| comparisons, and up to two components of level-of-detail information. |
| Buffer textures are not supported by normal texture lookup functions, |
| but are supported by TXF and TXQ, described below. Renderbuffer and |
| multisample textures are not supported by normal texture lookup |
| functions, but are supported by TXFMS. The TXB and TXL instructions are |
| not supported for the targets SHADOWARRAY2D and SHADOWARRAYCUBE, so the |
| first column of "lod" is ignored. |
| |
| Modify Section 2.X.8.Z, TXD: Texture Sample with Partials |
| |
| ... The partial derivatives of the texture coordinates with respect to X |
| and Y are specified by the second and third floating-point source vectors. |
| If the LODCLAMP instruction modifier is specified, floating-point |
| level-of-detail clamp value is specified in the <w> component of the third |
| floating-point source vector. The level of detail is computed |
| automatically using the provided partial derivatives. |
| |
| |
| Issues |
| |
| (1) How does this extension compare to the ARB_sparse_texture extension? |
| |
| RESOLVED: We extend the mechanisms provided by ARB_sparse_texture in |
| several ways: |
| |
| - We add built-in texture and image lookup functions returning |
| information on memory accesses performed by the built-in functions; |
| in particular, whether any uncommitted memory was referenced. |
| |
| - We add built-in texture and image lookup functions clamping the |
| final level of detail computed based on texture coordinates, |
| derivatives, and LOD bias to a minimum LOD specified in the shader. |
| |
| - We specify that all loads and atomics from uncommitted sparse memory |
| behave as though zero were fetched. |
| |
| - We remove the requirement that the base size of a sparse texture |
| must be a multiple of the page size. Implementations are expected |
| to pad mipmap allocations internally to page size boundaries as |
| required, until the tail is reached. |
| |
| - We modify the definition of the sparse texture mipmap tail, so that |
| all levels greater than or equal to the page size in all dimensions |
| are guaranteed to be sparsely populated (i.e., not in the tail). |
| The previous spec allowed implementations to put levels in the tail |
| if they were not integer multiples of the page size. |
| |
| - We add support for an implementation-independent virtual page size |
| for some formats, instead of depending on querying |
| implementation-dependent page size. For such formats, the default |
| virtual page size index (0) is guaranteed to specify the standard |
| page size. |
| |
| - We require that all implementations of this extension return TRUE |
| for the value of the implementation-dependent constant |
| SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS_ARB, which removes some |
| potential errors when allocating sparse array or cube map textures. |
| |
| - We add support for sparse multisample and multisample array |
| textures, but require no implementation-independent virtual page |
| size. |
| |
| (2) How does this extension compare to the AMD_sparse_texture extension? |
| |
| RESOLVED: This extension, like the AMD extension, provide built-in |
| texture lookup functions returning information on whether uncommitted |
| memory was accessed. There are several differences between these |
| functions: |
| |
| - This extension uses an "EXT" suffix on built-in function names. |
| |
| - This extension provides built-in functions supporting the sparse |
| return information together with the new LOD clamp feature. |
| |
| - This extension supports sparse accesses for shadow map sampler types |
| (e.g., sampler2DShadow). |
| |
| - This extension supports sparse variants of imageLoad(); the AMD |
| extension does not. |
| |
| - This extension doesn't attempt to support sparse variants of |
| projective texture lookups to reduce the number of texture functions |
| added. |
| |
| - This extension doesn't attempt to support sparse variants of |
| one-dimensional and one-dimensional array texture lookups. Sparse |
| textures with these targets are explicitly not supported in the ARB |
| extension. |
| |
| - This extension returns the texel data in an "out" parameter and |
| returns a value consistent with sampling zero in any uncommitted |
| texels. The AMD extension returns the texel data in an "inout" |
| parameter and guarantees not to write to the return value if any |
| uncommitted texel is accessed. |
| |
| - The function sparseTexelResident() from the AMD extension is renamed |
| to sparseTexelsResidentEXT(). We use "texels" instead of "texel" in |
| the function name because a texture lookup may access multiple |
| texels, and the code will reflect non-resident status if any of the |
| texels is non-resident. |
| |
| The built-in functions taking an explicit LOD clamp, returning zero on |
| reads from uncommitted memory, and the standard virtual page size are |
| not provided by the AMD extension, either. |
| |
| Neither this extension nor ARB_sparse_texture provide the minimum LOD |
| warning feature provided by the AMD extension or the related built-in |
| functions. |
| |
| (3) How should the "sparse" built-in functions return both access status |
| and a texel value? |
| |
| RESOLVED: We mostly followed the precedent of the AMD extension, where |
| the sparse access status is returned as an integer and the texel values |
| are returning in a vec4-typed "out" parameter. (This differs slightly |
| from the AMD extension in that it uses an "inout" parameter.) |
| |
| We considered included returning the texel values from the function, |
| just like normal texture lookups, and returning status in a separate |
| "out" parameter (reversing the order). We also considered returning a |
| structure type containing both the status and the texel. We ultimately |
| chose to return the status code to more closely match the AMD extension |
| and because we expect that shaders caring to use the "sparse" functions |
| will want to look at the status code first. |
| |
| (4) What data type should we use for the access status information |
| returned by the "sparse" built-in functions? |
| |
| RESOLVED: We chose to follow the precedent of the AMD extension, where |
| an integer code is returned. Requiring a separate function call |
| (sparseTexelsResidentEXT) is required to reason about the code returned |
| is mildly annoying, but we didn't consider it serious enough to warrant |
| a change. |
| |
| We could have used a "bool" type instead, but chose to stick with "int" |
| for compatibility and for possible future expansion. The AMD extension |
| also includes built-in functions sparseTexelMinLodWarning() and |
| sparseTexelWarningFetch() that can be used to check the return code for |
| other conditions not supported by this extension. Shaders that only |
| care about residency information can still check the status in a single |
| (long) line: |
| |
| if (!sparseTexelsResidentEXT(sparseTextureEXT(sampler, coords, |
| texel)) |
| { |
| // do something about the failure |
| } |
| |
| (5) When using a "sparse" built-in texture function, what RGBA values are |
| generated when the lookup accesses one or more uncommited texels? |
| |
| RESOLVED: We return a filtered result vector where memory for |
| uncommitted texels is treated as being filled with zeroes. The data |
| vector returned by the "sparse" functions for this case should exactly |
| match the vector returned by an equivalent non-"sparse" function. |
| |
| (6) For "sparse" built-in texture functions, where should the <texel> |
| return value go relative to other parameters? |
| |
| RESOLVED: We chose to follow the precedent of the AMD extension, |
| putting it in (approximately) the last parameter. Note that the |
| optional <bias> parameter of texture() breaks this pattern; we chose to |
| keep the optional bias at the end. |
| |
| Other options considered included: always first (before the sampler), |
| always second (after the sampler), always third (after the sampler and |
| the base coordinates). For "always third", note there are a couple |
| cases like shadow lookups in cube arrays where the coordinates are split |
| across multiple parameters and "always third" would be awkward. |
| Additional options are discussed in issue (3). |
| |
| (7) Should we provide sparse variants of the "2DMS" and "2DMSArray" |
| variants of texelFetch() and imageLoad() in this extension? |
| |
| RESOLVED: Yes. ARB_sparse_texture doesn't support multisample |
| textures. In this extension, we lift this restriction, allow them to be |
| accessed using normal built-ins, and provide new functions allowing |
| shaders to determine if uncommitted memory was accessed. |
| |
| (8) How does the feedback provided in the "sparse" built-in texture |
| functions interact with texture filtering modes involving multiple |
| texels? |
| |
| RESOLVED: The sparse texture lookup status will indicate that |
| uncommitted memory was accessed if any texel read during the filtering |
| operation was uncommitted, but will do so only if the filter weight is |
| non-zero. When applying a texture filter such as LINEAR_MIPMAP_LINEAR, |
| it's possible that the interpolated texture coordinate lines up exactly |
| at the center of a texel and/or exactly at an integer level of detail. |
| According to the standard filtering equations, eight samples are taken |
| -- four in each of two levels. However, it's possible that only one of |
| the eight samples has a non-zero weight (if the coordinates hit a texel |
| center and the LOD is an integer). |
| |
| This "non-zero weight" feature may be important for getting proper |
| feedback in some cases, such as displaying a texture tile with an |
| aligned 1:1 mapping of pixels to texels or forcing a specific level of |
| detail in some cases. Note that when attempting to apply a 1:1 mapping |
| of pixels to texels via an interpolated texture attribute, it's possible |
| that small floating-point errors might produce very small but non-zero |
| weights for neighboring texels. If avoiding such errors is important |
| and a 1:1 mapping is required, a single-sample filter like NEAREST |
| should be used. |
| |
| (9) Should we support sparse texel fetches and image loads for buffer |
| textures? |
| |
| RESOLVED: Not in this extension. This should be handled by a separate |
| extension allowing for the creation and use of sparse buffer resources. |
| Such an extension might also provide the ability to get "sparse" |
| information when non-texture mechanisms are used to access memory (e.g., |
| ARB_shader_storage_buffer_object, NV_shader_buffer_load). |
| |
| (10) Should we support "sparse" variants of the image atomic functions |
| that return information on residency as well as the value normally |
| returned by the atomic operation? |
| |
| RESOLVED: Not in this extension; it's not clear that there's an |
| important use case for this. If required, a shader can use imageLoad() |
| to probe the residency of a given texel and ignore the data values |
| returned. |
| |
| (11) This extension is adding a *large* number of new built-in functions. |
| What can we do to control this? |
| |
| RESOLVED: We chose not to add any "sparse" or "LOD clamp" variants of |
| projective texture lookups (e.g., textureProj). If required, you can |
| divide through by the "q" texture coordinate and use an equivalent |
| non-projective lookup. |
| |
| We obviously don't support features that make no sense -- for example, |
| LOD clamp on single-level rectangle textures. |
| |
| We considered the possibility of more significant GLSL syntax changes to |
| reduce the cross-product of different features. For example, the AMD |
| extension has a function: |
| |
| int sparseTextureProjGradOffset(...); |
| |
| that combines four separate "optional" features (sparse, projection, |
| explicitly specified gradients, and texel offsets) and is supported for |
| six separate texture targets. One might consider an approach like: |
| |
| #define TEX_IS_PROJECTIVE 0x1 |
| #define TEX_HAS_GRADIENTS 0x2 |
| #define TEX_HAS_TEXEL_OFFSET 0x4 |
| #define TEX_WANTS_SPARSE_STATUS 0x8 |
| struct TexLookup3D { |
| uint flags; /* in */ |
| float q; /* in */ |
| vec3 ddx, ddy; /* in */ |
| ivec3 texelOffset; /* in */ |
| int sparseStatus; /* out */ |
| }; |
| ... |
| TexLookup3D lookup; |
| lookup.flags = (TEX_IS_PROJECTIVE | TEX_HAS_GRADIENTS | |
| TEX_HAS_TEXEL_OFFSET | TEX_WANTS_SPARSE_STATUS); |
| lookup.q = coords.w; |
| lookup.ddx = ddx; |
| lookup.ddy = ddy; |
| lookup.texelOffset = ivec3(-1,+1,+2); |
| texture(sampler, lookup); |
| |
| to handle all possible cases in one interface. Alternately, a |
| "prettier" C++-style approach with methods on sampler classes could be |
| used. |
| |
| Given that either such feature might involve a large change to the |
| shading language, it seems more appropriate to address this issue in a |
| future core version of a shading language rather than an extension. |
| |
| (12) For new "LOD clamp" functions, how does the LOD clamp interact with |
| the LOD bias? |
| |
| RESOLVED: The LOD clamp is applied after the LOD bias. Clamping to the |
| LOD provided in the shader is logically applied at the same point in the |
| pipeline where the LOD clamps based on the texture/sampler parameters |
| TEXTURE_{MIN,MAX}_LOD are applied. |
| |
| (13) How does the "reads produce zero" behave if a sparse texture is bound |
| to a framebuffer and used for the depth or stencil test? |
| |
| RESOLVED: The depth and stencil tests act as though zero were read from |
| the framebuffer. The actual results of the tests depend on the depth |
| and stencil functions, the incoming depth value, and the stencil |
| reference value. |
| |
| There may be cases where it might be advantageous to configure the depth |
| or stencil tests to fail when touching an unpopulated portion of the |
| depth/stencil buffer. The "return zero" behavior may work well for some |
| cases (e.g., returning zero when using a depth test of LESS will cause |
| the test to almost always fail), but not as well for others (e.g., depth |
| test of GREATER). We've chosen not to address this case in the current |
| extension. |
| |
| (14) How does the "reads produce zero" behave for textures that don't have |
| all four components? |
| |
| RESOLVED: Components that are present in the texture will return zero; |
| others will return default values. For example, an access to an |
| uncommitted sparse texture whose with a format has no alpha component |
| (e.g, RGB8) will return 1.0 on the alpha channel of the returned RGBA |
| vector. The handling of "missing" components is the same as for |
| non-sparse textures. |
| |
| (15) Should we provide standard sparse texture page sizes that |
| applications can rely on without having to query the set of supported |
| page sizes for each format it uses? If so, how will this be handled? |
| Will we have some formats that have standard sizes and others that |
| don't? |
| |
| RESOLVED: Yes; we will provide standard page sizes for some, but not |
| all, formats. However, we will still allow for implementation- |
| dependent page sizes (as in ARB_sparse_textures) for formats that have a |
| standard page size and allow implementations to support sparse textures |
| on formats for which a standard page size is not available. The basic |
| page sizes we use arrange sparse textures into 64KB pages and attempt to |
| keep the X, Y, and Z (for 3D) dimensions of the page roughly equal. |
| |
| (16) Should we add specific compressed formats to the required formats list |
| and provide standard page sizes? |
| |
| RESOLVED: Not in this extension. Note that the current |
| ARB_sparse_texture extension already allows implementations to support |
| compressed formats. |
| |
| We've chosen not to go to the trouble of enumerating standard page sizes |
| for all the compressed formats (many of which are added by extension), |
| but one logical approach would be to treat each 64- or 128-bit block in |
| common formats as a single logical texel and treat the standard page |
| sizes of 64- and 128-bit texels as being in units of compression blocks. |
| |
| (17) How do applications get to use the standard page size? |
| |
| RESOLVED: Applications opt in to using standard page sizes by leaving |
| VIRTUAL_PAGE_SIZE_INDEX_ARB at its initial value (zero). |
| |
| In ARB_sparse_texture, there were no standard page sizes. Applications |
| can use GetInternalformativ() with <pname> of NUM_VIRTUAL_PAGE_SIZES_ARB |
| to query the implementation-dependent number of page sizes supported for |
| any given format. Some formats may be unsupported, and the GL will |
| return a page size count of zero. Other formats may have a page size |
| count of one, or more than one if the implementation supports multiple |
| page sizes. An application can query the properties of each page size |
| index by calling GetInternalFormativ() with <pname> set to |
| VIRTUAL_PAGE_SIZE_{X,Y,Z}_ARB. When an application determines the page |
| size it wants to use from the options returned by the GL, it sets the |
| VIRTUAL_PAGE_SIZE_INDEX_ARB texture parameter prior to calling |
| TexStorage* to allocate storage for the sparse texture. |
| |
| If an application doesn't bother setting the VIRTUAL_PAGE_SIZE_INDEX_ARB |
| texture parameter, the default index of zero will be used and the page |
| size will be whatever the implementation chooses for its first page size |
| index. In the absence of this extension, the application still needs to |
| call GetInternalFormativ() to determine the page size being used so it |
| can manage texture residency. But in the presence of this extension, page |
| size index 0 will be a standard size and will be the same on all |
| implementations supporting the extension. |
| |
| (18) Should we support sparse multisample textures? If so, should we |
| support standard virtual page sizes? |
| |
| RESOLVED: Yes, we add will support for sparse multisample textures, but |
| will not specify standard page sizes. |
| |
| Different implementations of this extension may represent multisample |
| textures in different ways. Some implementations might interleave |
| samples in memory, while others might have separate "planes" in memory |
| for each individual sample. If we were to support a standard page size, |
| the easiest approach might be to have a greatest-common-multiple |
| standard page size. For example, the standard page size for |
| single-sample textures with 32-bit texels is 128x128 (64KB total). We |
| could choose to use the same page size for multisample textures. For 4x |
| multisample, a page of 128x128 pixels would have an effective page size |
| of 256KB. If an implementation interleaves samples, each virtual page |
| might be assembled from four consecutive 64K physical pages. If an |
| implementation has separate "planes", the virtual page might be |
| assembled from four 64K physical pages spread out in memory. |
| |
| (19) Should we require support for sparse depth or stencil textures? |
| Sparse support for these formats is optional in ARB_sparse_texture. |
| If so, should we support standard virtual page sizes? |
| |
| RESOLVED: Not in this extension. |
| |
| The current ARB_sparse_texture extension already allows implementations |
| to support sparse depth/stencil formats, so the only things a change |
| could accomplish is (a) provide standard page sizes that can be used |
| without querying implementation page sizes, (b) ensure that apps can |
| rely on *some* support by just checking the extension without querying |
| the number of supported page sizes via GetInternalFormat. |
| |
| We expect that different implementations may store depth and stencil |
| textures in different ways and might have different "natural" page |
| sizes. We could deal with this by using a greatest-common-multiple |
| standard page size (i.e., have a standard page size larger than 64K), |
| but it's not clear if that will fly. |
| |
| The advantages of (b) seem low relative to (a), so we aren't proposing |
| to add depth and stencil formats to the required list for this |
| extension. |
| |
| (20) Should we make a separate extension for the LOD clamp GLSL functions? |
| |
| RESOLVED: No. While the LOD clamp function doesn't have any real |
| interaction with sparse textures, its intent is to force the use of a |
| coarser level of detail that is known (or suspected) to be populated. |
| We expect that applications using sparse textures may make some of the |
| coarser levels of detail fully resident, but make portions finer levels |
| of detail resident selectively. Without using the feedback mechanism |
| (from the sparseTexture*) functions or without being able to have |
| portions of the texture non-resident, the LOD clamp built-ins don't |
| really make much sense. |
| |
| (21) Should we reconsider re-examining some of the non-orthogonalities in |
| the current set of texture built-ins, which are being extended for |
| sparse. For example, the texture() built-in for a sampler type of |
| samplerCubeArrayShadow does not include an optional LOD bias despite |
| the fact that cubemap arrays do support multiple LODs. |
| |
| RESOLVED: Not in this extension. |
| |
| We chose to create "sparse" variants of existing built-ins without |
| re-examining current capabilities. It might make sense to have an |
| extension or future core shading language re-examine things and improve |
| orthogonality if implementations can support it. |
| |
| Revision History |
| |
| Revision 1 |
| - Internal revisions |
| Revision 2 - December 18, 2014 - mheyer |
| - added ES 3.1 interactions |
| Revision 3 - April 19, 2016 - dkoch |
| - fix typos, add interactions with OES extensions |
