Name ARB_texture_view Name Strings GL_ARB_texture_view Contact Jeff Bolz, NVIDIA Corporation (jbolz 'at' nvidia.com) Contributors Pat Brown, NVIDIA Daniel Koch, TransGaming Jon Leech Notice Copyright (c) 2012-2013 The Khronos Group Inc. Copyright terms at http://www.khronos.org/registry/speccopyright.html Specification Update Policy Khronos-approved extension specifications are updated in response to issues and bugs prioritized by the Khronos OpenGL Working Group. For extensions which have been promoted to a core Specification, fixes will first appear in the latest version of that core Specification, and will eventually be backported to the extension document. This policy is described in more detail at https://www.khronos.org/registry/OpenGL/docs/update_policy.php Status Complete. Approved by the ARB on 2012/06/12. Version Last Modified Date: July 15, 2013 Revision: 4 Number ARB Extension #124 Dependencies This extension is written against the OpenGL 4.2 Core profile specification. ARB_texture_storage or OpenGL 4.2 is required. ARB_internalformat_query2 interacts with this extension. EXT_texture_compression_s3tc interacts with this extension. EXT_texture_sRGB interacts with this extension. ARB_texture_storage_multisample interacts with this extension. Overview This extension allows a texture's data store to be "viewed" in multiple ways, either reinterpreting the data format/type as a different format/ type with the same element size, or by clamping the mipmap level range or array slice range. The goals of this extension are to avoid having these alternate views become shared mutable containers of shared mutable objects, and to add the views to the API in a minimally invasive way. No new object types are added. Conceptually, a texture object is split into the following parts: - A data store holding texel data. - State describing which portions of the data store to use, and how to interpret the data elements. - An embedded sampler object. - Various other texture parameters. With this extension, multiple textures can share a data store and have different state describing which portions of the data store to use and how to interpret the data elements. The data store is refcounted and not destroyed until the last texture sharing it is deleted. This extension leverages the ARB_texture_storage concept of an "immutable texture". Views can only be created of textures created with TexStorage. New Procedures and Functions void TextureView(uint texture, enum target, uint origtexture, enum internalformat, uint minlevel, uint numlevels, uint minlayer, uint numlayers); New Tokens Accepted by the parameters of GetTexParameterfv and GetTexParameteriv: TEXTURE_VIEW_MIN_LEVEL 0x82DB TEXTURE_VIEW_NUM_LEVELS 0x82DC TEXTURE_VIEW_MIN_LAYER 0x82DD TEXTURE_VIEW_NUM_LAYERS 0x82DE TEXTURE_IMMUTABLE_LEVELS 0x82DF Used as compatibility class names in table 3.X.2 (see the "Interactions with ARB_internalformat_query2" section below). VIEW_CLASS_128_BITS VIEW_CLASS_96_BITS VIEW_CLASS_64_BITS VIEW_CLASS_48_BITS VIEW_CLASS_32_BITS VIEW_CLASS_24_BITS VIEW_CLASS_16_BITS VIEW_CLASS_8_BITS VIEW_CLASS_S3TC_DXT1_RGB VIEW_CLASS_S3TC_DXT1_RGBA VIEW_CLASS_S3TC_DXT3_RGBA VIEW_CLASS_S3TC_DXT5_RGBA VIEW_CLASS_RGTC1_RED VIEW_CLASS_RGTC2_RG VIEW_CLASS_BPTC_UNORM VIEW_CLASS_BPTC_FLOAT Additions to Chapter 2 of the OpenGL 4.2 Specification (OpenGL Operation) None. Additions to Chapter 3 of the OpenGL 4.2 Specification (Rasterization) Modify subsection 3.9.8 (Texture Parameters) Add the following to the end of the paragraph on p. 240: If the texture was created with TextureView, then the TEXTURE_BASE_LEVEL and TEXTURE_MAX_LEVEL parameters are interpreted relative to the view and not relative to the original data store. Modify subsection 3.9.15 (Texture State and Proxy State) Add to the second paragraph on p. 256: The values of TEXTURE_IMMUTABLE_LEVELS, TEXTURE_VIEW_MIN_LEVEL, TEXTURE_VIEW_NUM_LEVELS, TEXTURE_VIEW_MIN_LAYER, TEXTURE_VIEW_NUM_LAYERS are 0. Modify subsection 3.9.16 (Immutable-Format Texture Images) Modify the second to last bullet on p. 258: If the command is successful, TEXTURE_IMMUTABLE_FORMAT becomes TRUE, TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become . If the texture target is TEXTURE_1D_ARRAY then TEXTURE_VIEW_NUM_LAYERS becomes . If the texture target is TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY, or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS becomes . If the texture target is TEXTURE_CUBE_MAP, then TEXTURE_VIEW_NUM_LAYERS becomes 6. For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes 1. Add a new subsection at the end of 3.9 (Texturing) 3.9.X Texture Views A texture can be created which references the data store of another texture and interprets the data with a different format, and/or selects a subset of the levels and/or layers of the other texture. The data store for such a texture is shared with the data store of the original texture. Updating the shared data store using the original texture affects texture values read using the new texture, and vice versa. A texture data store remains in existence until all textures that reference it are deleted. The command: void TextureView(uint texture, enum target, uint origtexture, enum internalformat, uint minlevel, uint numlevels, uint minlayer, uint numlayers); initializes the texture named to the target specified by . 's data store is inherited from the texture named , but elements of the data store are interpreted according to the internal format specified by . Additionally, if the original texture is an array or has multiple mipmap levels, the parameters , , , and control which of those slices and levels are considered part of the texture. The and parameters are relative to the view of the original texture. If or extend beyond the original texture, they are clamped to the max extent of the original texture. If or are larger than the greatest level or layer of the original texture, the error INVALID_VALUE is generated. If the command is successful, the texture parameters in are updated as follows: - TEXTURE_IMMUTABLE_FORMAT is set to TRUE. - TEXTURE_IMMUTABLE_LEVELS is set to the value of TEXTURE_IMMUTABLE_LEVELS from the original texture. - TEXTURE_VIEW_MIN_LEVEL is set to plus the value of TEXTURE_VIEW_MIN_LEVEL from the original texture. - TEXTURE_VIEW_MIN_LAYER is set to plus the value of TEXTURE_VIEW_MIN_LAYER from the original texture. - TEXTURE_VIEW_NUM_LEVELS is set to the lesser of and the value of TEXTURE_VIEW_NUM_LEVELS from the original texture minus . - TEXTURE_VIEW_NUM_LAYERS is set to the lesser of and the value of TEXTURE_VIEW_NUM_LAYERS from the original texture minus . The new texture's target must be "compatible" with the target of the original texture, or else an INVALID_OPERATION error is generated. Compatibility is defined by Table 3.X.1: --------------------------------------------------------------------------------------------------------- | Original target | Valid new targets | --------------------------------------------------------------------------------------------------------- | TEXTURE_1D | TEXTURE_1D, TEXTURE_1D_ARRAY | |-------------------------------------------------------------------------------------------------------| | TEXTURE_2D | TEXTURE_2D, TEXTURE_2D_ARRAY | |-------------------------------------------------------------------------------------------------------| | TEXTURE_3D | TEXTURE_3D | |-------------------------------------------------------------------------------------------------------| | TEXTURE_CUBE_MAP | TEXTURE_CUBE_MAP, TEXTURE_2D, TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY | |-------------------------------------------------------------------------------------------------------| | TEXTURE_RECTANGLE | TEXTURE_RECTANGLE | |-------------------------------------------------------------------------------------------------------| | TEXTURE_BUFFER | | |-------------------------------------------------------------------------------------------------------| | TEXTURE_1D_ARRAY | TEXTURE_1D_ARRAY, TEXTURE_1D | |-------------------------------------------------------------------------------------------------------| | TEXTURE_2D_ARRAY | TEXTURE_2D_ARRAY, TEXTURE_2D, TEXTURE_CUBE_MAP, TEXTURE_CUBE_MAP_ARRAY | |-------------------------------------------------------------------------------------------------------| | TEXTURE_CUBE_MAP_ARRAY | TEXTURE_CUBE_MAP_ARRAY, TEXTURE_2D_ARRAY, TEXTURE_2D, TEXTURE_CUBE_MAP | |-------------------------------------------------------------------------------------------------------| | TEXTURE_2D_MULTISAMPLE | TEXTURE_2D_MULTISAMPLE, TEXTURE_2D_MULTISAMPLE_ARRAY | |-------------------------------------------------------------------------------------------------------| | TEXTURE_2D_MULTISAMPLE_ARRAY| TEXTURE_2D_MULTISAMPLE, TEXTURE_2D_MULTISAMPLE_ARRAY | --------------------------------------------------------------------------------------------------------- Table 3.X.1: Legal texture targets for TextureView. If the new texture's target is TEXTURE_CUBE_MAP, the clamped must be equal to 6. If the new texture's target is TEXTURE_CUBE_MAP_ARRAY, then counts layer-faces rather than layers, and the clamped must be a multiple of 6. Otherwise, the error INVALID_VALUE is generated. If the new texture's target is TEXTURE_CUBE_MAP or TEXTURE_CUBE_MAP_ARRAY, the width and height of the original texture's levels must be equal otherwise the error INVALID_OPERATION is generated. When the original texture's target is TEXTURE_CUBE_MAP, the layer parameters are interpreted in the same order as if it were a TEXTURE_CUBE_MAP_ARRAY with 6 layer-faces. If is TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_RECTANGLE, or TEXTURE_2D_MULTISAMPLE and does not equal 1, the error INVALID_VALUE is generated. If the dimensions of the original texture are larger than the maximum supported dimensions of the new target, the error INVALID_OPERATION is generated. For example, if the original texture has a TEXTURE_2D_ARRAY target and its width is greater than MAX_CUBE_MAP_TEXTURE_SIZE, an error will be generated if TextureView is called to create a TEXTURE_CUBE_MAP view. The two textures' internal formats must be compatible according to Table 3.X.2 (Compatible internal formats for TextureView) if the internal format exists in that table and the internal formats must be identical if not in that table, or else an INVALID_OPERATION error is generated. --------------------------------------------------------------------------- | Class | Internal formats | --------------------------------------------------------------------------- | VIEW_CLASS_128_BITS | RGBA32F, RGBA32UI, RGBA32I | --------------------------------------------------------------------------- | VIEW_CLASS_96_BITS | RGB32F, RGB32UI, RGB32I | --------------------------------------------------------------------------- | VIEW_CLASS_64_BITS | RGBA16F, RG32F, RGBA16UI, RG32UI, RGBA16I, | | | RG32I, RGBA16, RGBA16_SNORM | --------------------------------------------------------------------------- | VIEW_CLASS_48_BITS | RGB16, RGB16_SNORM, RGB16F, RGB16UI, RGB16I | --------------------------------------------------------------------------- | VIEW_CLASS_32_BITS | RG16F, R11F_G11F_B10F, R32F, | | | RGB10_A2UI, RGBA8UI, RG16UI, R32UI, | | | RGBA8I, RG16I, R32I, RGB10_A2, RGBA8, RG16, | | | RGBA8_SNORM, RG16_SNORM, SRGB8_ALPHA8, RGB9_E5 | --------------------------------------------------------------------------- | VIEW_CLASS_24_BITS | RGB8, RGB8_SNORM, SRGB8, RGB8UI, RGB8I | --------------------------------------------------------------------------- | VIEW_CLASS_16_BITS | R16F, RG8UI, R16UI, RG8I, R16I, RG8, R16, | | | RG8_SNORM, R16_SNORM | --------------------------------------------------------------------------- | VIEW_CLASS_8_BITS | R8UI, R8I, R8, R8_SNORM | --------------------------------------------------------------------------- | VIEW_CLASS_RGTC1_RED | COMPRESSED_RED_RGTC1, | | | COMPRESSED_SIGNED_RED_RGTC1 | --------------------------------------------------------------------------- | VIEW_CLASS_RGTC2_RG | COMPRESSED_RG_RGTC2, | | | COMPRESSED_SIGNED_RG_RGTC2 | --------------------------------------------------------------------------- | VIEW_CLASS_BPTC_UNORM | COMPRESSED_RGBA_BPTC_UNORM, | | | COMPRESSED_SRGB_ALPHA_BPTC_UNORM | --------------------------------------------------------------------------- | VIEW_CLASS_BPTC_FLOAT | COMPRESSED_RGB_BPTC_SIGNED_FLOAT, | | | COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT | --------------------------------------------------------------------------- Table 3.X.2: Compatible internal formats for TextureView. Formats in the same entry may be cast to each other. If the internal format does not exactly match the internal format of the original texture, the contents of the memory are reinterpreted in the same manner as for image bindings described in section 3.9.20 (Texture Image Loads and Stores). If has already been bound and given a target, then the error INVALID_OPERATION is generated. If is 0, INVALID_VALUE is generated. If is not a valid name returned by GenTextures, the error INVALID_OPERATION is generated. If is not the name of a texture, INVALID_VALUE is generated. If 's TEXTURE_IMMUTABLE_FORMAT value is not TRUE, INVALID_OPERATION is generated. Texture commands that take a or parameter, such as TexSubImage2D, interpret that parameter to be relative to the view of the texture. i.e. the mipmap level of the data store that would be updated via TexSubImage2D would be the sum of and the value of TEXTURE_VIEW_MIN_LEVEL. Additions to Chapter 4 of the OpenGL 4.2 Specification (Per-Fragment Operations and the Frame Buffer) None. Additions to Chapter 5 of the OpenGL 4.2 Specification (Special Functions) None. Additions to Chapter 6 of the OpenGL 4.2 Specification (State and State Requests) Modify subsection 6.1.3 (Enumerated Queries) Modify the paragraph after GetTexParameter on p. 350: ... must be IMAGE_FORMAT_COMPATIBILITY_TYPE, TEXTURE_IMMUTABLE_FORMAT, TEXTURE_VIEW_MIN_LEVEL, TEXTURE_VIEW_NUM_LEVELS, TEXTURE_VIEW_MIN_LAYER, TEXTURE_VIEW_NUM_LAYERS, or TEXTURE_IMMUTABLE_LEVELS. Additions to Appendix D of the OpenGL 4.2 Specification (Shared Objects and Multiple Contexts) Modify section D.3 (Propagating Changes to Objects) Modify the second bullet point on p 461: - The contents of the data stores of textures and renderbuffers. Add the following sentence to the paragraph that begins "When the contents of an object ": When is a texture, "the contents of an object " should be construed to include the contents of the data store of , even if 's data store was modified via a different view of the data store. Additions to the AGL/GLX/WGL Specifications None. GLX Protocol TBD Dependencies on EXT_texture_compression_s3tc If EXT_texture_compression_s3tc and EXT_texture_sRGB are supported, then Table 3.X.2 is updated to add the following rows: ------------------------------------------------------------------- | Class | Internal formats | ------------------------------------------------------------------- | VIEW_CLASS_S3TC_DXT1_RGB | COMPRESSED_RGB_S3TC_DXT1_EXT, | | | COMPRESSED_SRGB_S3TC_DXT1_EXT | ------------------------------------------------------------------- | VIEW_CLASS_S3TC_DXT1_RGBA | COMPRESSED_RGBA_S3TC_DXT1_EXT, | | | COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT | ------------------------------------------------------------------- | VIEW_CLASS_S3TC_DXT3_RGBA | COMPRESSED_RGBA_S3TC_DXT3_EXT, | | | COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT | ------------------------------------------------------------------- | VIEW_CLASS_S3TC_DXT5_RGBA | COMPRESSED_RGBA_S3TC_DXT5_EXT, | | | COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT | ------------------------------------------------------------------- Interactions with ARB_internalformat_query2 The VIEW_CLASS_* tokens used as compatibility class names in table 3.X.2 are the same tokens returned by the VIEW_COMPATIBILITY_CLASS query in ARB_internalformat_query2. In this extension they are simply a labelling mechanism and serve no functional purpose in the API, so their numeric values are not specified. Dependencies on ARB_texture_storage_multisample Views are only supported for textures created by TexStorage. The original ARB_texture_storage extension did not include TexStorage commands for multisample textures. These are added by ARB_texture_storage_multisample, so without that extension multisample textures cannot be used with views. Errors TODO New State Changes to table 6.16, p. 277 (Texture, state per texture object) Initial Get Value Type Get Command Value Description Sec. Attribute --------- ---- ----------- ------- ----------- ---- --------- TEXTURE_VIEW_MIN_LEVEL Z+ GetTexParameter 0 view base texture level 3.9.X texture TEXTURE_VIEW_NUM_LEVELS Z+ GetTexParameter 0 view number of texture levels 3.9.X texture TEXTURE_VIEW_MIN_LAYER Z+ GetTexParameter 0 view min array layer 3.9.X texture TEXTURE_VIEW_NUM_LAYERS Z+ GetTexParameter 0 view number of array layers 3.9.X texture TEXTURE_IMMUTABLE_LEVELS Z+ GetTexParameter 0 storage number of levels 3.9.X texture New Implementation Dependent State None. Examples TODO Issues (1) What internal formats can be cast to what other formats? RESOLVED: In general, we try to follow the precedent from ARB_shader_image_load_store where formats with the same element size can be cast to each other. Some specific issues with that: - Depth formats cannot be cast to other formats. D3D1x handles depth formats differently than GL, depth formats are not texturable and instead there are equivalent "RG" formats for each depth format. In GL, depth formats are all texturable and we don't have equivalent RG formats for most of them (we only have R32F and R16). Since these can be textured from in GL, there's no great need to cast them. - Compressed formats can only be cast to other compressed formats with nearly identical encodings. Only the sRGB/signed-ness can change. See also issue (10). - RGB formats cannot be cast to/from RGBA. For the case of RGBA->RGB, the same can be accomplished using ARB_texture_swizzle. For the case of RGB->RGBA, an RGB texture may have been allocated without storage for alpha bits so this needs to be disallowed. (2) Should TEXTURE_IMMUTABLE_FORMAT be renamed? ARB_texture_storage isn't really about the format being immutable, it's more about the data store not needing to be reallocated. This extension allows interpreting the data store with a different format, so this enum now feels poorly named. RESOLVED: Leave it as is. (3) Is it possible to create a texture view using an original texture which is itself a view? And if so, how are the level/layer values interpreted? RESOLVED: It is legal. For example, let's say texture 1 is a 2D_ARRAY texture with 200 layers. It will have TEXTURE_VIEW_MIN_LAYER=0, TEXTURE_VIEW_NUM_LAYERS=200. Then we create texture 2 from texture 1 using =100, =100. It will have TEXTURE_VIEW_MIN_LAYER=100, TEXTURE_VIEW_NUM_LAYERS=100. Then we create texture 3 from texture 2 using =50, =50. It will have TEXTURE_VIEW_MIN_LAYER=150, TEXTURE_VIEW_NUM_LAYERS=50. (4) Should we allow views of textures not created through TexStorage? RESOLVED: No. It might be possible, but if TexImage is called on a texture whose data store is shared it would likely require orphaning the old data store and creating/copying to a new data store. That's not desirable. (5) How are TEXTURE_BASE_LEVEL and TEXTURE_MAX_LEVEL interpreted if TEXTURE_VIEW_MIN_LEVEL is non-zero? RESOLVED: The intent is that TEXTURE_BASE_LEVEL is relative to the view, i.e. the base level is TEXTURE_BASE_LEVEL+TEXTURE_VIEW_MIN_LEVEL relative to the data store. (6) Do we need any new "typeless" formats? RESOLVED: No. Any "compatible" format can be used in place of a typeless format. (7) Why aren't BUFFER textures supported? RESOLVED: The same can be accomplished with the contemporaneous GL_ARB_texture_buffer_range extension. (8) This extension requires TEXTURE_IMMUTABLE_FORMAT to be TRUE, but we don't have TexStorage*Multisample. Should we add these commands, or not require immutable format? RESOLVED: Add TexStorage*Multisample. This is done by ARB_texture_storage_multisample. (9) Should it be possible to create a 2D view from a RECTANGLE texture or vice versa? RESOLVED: No. These targets may have different max dimensions, or may be allocated in memory with different tiling/swizzling. (10) Should it be possible to view a compressed texture in such a way that a block of the compressed view corresponds to a texel of an uncompressed view? For example, taking a 256x256 DXT1 texture and viewing it as a 64x64 RG32UI texture? RESOLVED: No. The different mipmap stack sizes would be a problem, and it's unclear whether all hardware could support this. Maybe a future extension could enable this, but only allowing the view to have a single level? (11) Interaction between TEXTURE_IMMUTABLE_LEVELS and View textures? RESOLVED: There are several new TexParameter queries, and the values they return depend on how the texture was created: - If the texture is in its initial state or the data store was created with TexImage, then all five new parameters are zero. - If the texture was created with TexStorage, then the parameters take their values from the arguments, with both MIN parameters being zero, both LEVELS parameters being , and NUM_LAYERS being the number of layers if it's an array texture. - If the texture was created with TextureView, then the VIEW parameters describe the texture's subset of the entire data store, and IMMUTABLE_LEVELS is inherited from the original texture. (12) Are uses of two different views of the same data store automatically coherent? RESOLVED: Yes, to the extent that they were for a single texture. A few examples of this are: - TexSubImage to view A followed by texturing from view B. - Rendering to view A attached to an FBO followed by texturing from view B. - Shader image stores to view A followed by texturing from view B. The first two cases would automatically work correctly if A and B were the same texture, as described in Appendix D, so they continue to work with separate views. If an implementation were (for example) tracking uses of the texture to do cache invalidations, it should do such tracking on the data store instead. The third case would not automatically work if A and B were the same texture, instead requiring a MemoryBarrier call to force coherency. This same solution applies with texture views. (13) Are interactions with ETC2/EAC compressed texture formats defined? RESOLVED: No. It is likely that these formats are emulated with uncompressed internal formats on older hardware, and the resulting complications make defining texture view classes for these formats too difficult for too little functionality. Revision History Rev. Date Author Changes ---- -------- -------- ----------------------------------------- 5 10/08/13 Jon Leech Add issue 13 discussing why ETC2/EAC view classes aren't supported (Bug 11011). 4 07/15/13 Jon Leech Change "Class" column of table 3.X.2 from abstract names to VIEW_CLASS_* enums from ARB_internalformat_query2 (Bug 10518). 3 08/13/12 Jon Leech Renumbered from #142 to #124 2 05/07/12 dgkoch Added class names to Table 3.X.2 1 jbolz Internal revisions.