1Name 2 3 ARB_texture_swizzle 4 5Name Strings 6 7 GL_ARB_texture_swizzle 8 9Contact 10 11 Jeff Bolz, NVIDIA Corporation (jbolz 'at' nvidia.com) 12 13Contributors 14 15 Cass Everitt, Id Software 16 Brian Harris, Id Software 17 Pat Brown, NVIDIA 18 Eric Werness, NVIDIA 19 20Notice 21 22 Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at 23 http://www.khronos.org/registry/speccopyright.html 24 25Specification Update Policy 26 27 Khronos-approved extension specifications are updated in response to 28 issues and bugs prioritized by the Khronos OpenGL Working Group. For 29 extensions which have been promoted to a core Specification, fixes will 30 first appear in the latest version of that core Specification, and will 31 eventually be backported to the extension document. This policy is 32 described in more detail at 33 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 34 35Status 36 37 Complete. Approved by the ARB at the 2010/01/22 F2F meeting. 38 Approved by the Khronos Board of Promoters on March 10, 2010. 39 40Version 41 42 Last Modified Date: December 7, 2009 43 Author Revision: 1.0 44 45Number 46 47 ARB Extension #84 48 49Dependencies 50 51 Written based on the wording of the OpenGL 2.1 specification. 52 53Overview 54 55 Classic OpenGL texture formats conflate texture storage and 56 interpretation, and assume that textures represent color. In 57 modern applications, a significant quantity of textures don't 58 represent color, but rather data like shadow maps, normal maps, 59 page tables, occlusion data, etc.. For the latter class of data, 60 calling the data "RGBA" is just a convenient mapping of what the 61 data is onto the current model, but isn't an accurate reflection 62 of the reality of the data. 63 64 The existing texture formats provide an almost orthogonal set of 65 data types, sizes, and number of components, but the mappings of 66 this storage into what the shader or fixed-function pipeline 67 fetches is very much non-orthogonal. Previous extensions have 68 added some of the most demanded missing formats, but the problem 69 has not been solved once and for all. 70 71 This extension provides a mechanism to swizzle the components 72 of a texture before they are applied according to the texture 73 environment in fixed-function or as they are returned to the 74 shader. 75 76IP Status 77 78 No known IP claims. 79 80New Procedures and Functions 81 82 None 83 84New Tokens 85 86 Accepted by the <pname> parameters of TexParameteri, 87 TexParameterf, TexParameteriv, TexParameterfv, 88 GetTexParameterfv, and GetTexParameteriv: 89 90 TEXTURE_SWIZZLE_R 0x8E42 91 TEXTURE_SWIZZLE_G 0x8E43 92 TEXTURE_SWIZZLE_B 0x8E44 93 TEXTURE_SWIZZLE_A 0x8E45 94 95 Accepted by the <pname> parameters of TexParameteriv, 96 TexParameterfv, GetTexParameterfv, and GetTexParameteriv: 97 98 TEXTURE_SWIZZLE_RGBA 0x8E46 99 100 101Additions to Chapter 2 of the OpenGL 2.1 Specification (OpenGL Operation) 102 103 Modify Section 2.15.4 (Shader Execution), p. 84: 104 105 Texture Access 106 107 ...and converts it to a texture source color Cs according to table 108 3.20 (section 3.8.13), followed by application of the texture swizzle 109 as described in section 3.8.13. A four-component vector (Rs,Gs,Bs,As) 110 is returned to the vertex shader. 111 112Additions to Chapter 3 of the OpenGL 2.1 Specification (Rasterization) 113 114 Modify Section 3.8.4 (Texture Parameters), p. 168: 115 116 (modify table 3.18, p. 169) 117 Name Type Legal Values 118 ---- ---- ------------ 119 TEXTURE_SWIZZLE_R enum RED, GREEN, BLUE, ALPHA, ZERO, ONE 120 TEXTURE_SWIZZLE_G enum RED, GREEN, BLUE, ALPHA, ZERO, ONE 121 TEXTURE_SWIZZLE_B enum RED, GREEN, BLUE, ALPHA, ZERO, ONE 122 TEXTURE_SWIZZLE_A enum RED, GREEN, BLUE, ALPHA, ZERO, ONE 123 124 (append to section 3.8.4, p. 170) 125 126 TEXTURE_SWIZZLE_RGBA sets the same state as the R, G, B, A enums in a 127 single call. 128 129 (append to section 3.8.13, p. 184) 130 The values of the texture parameters TEXTURE_SWIZZLE_R, 131 TEXTURE_SWIZZLE_G, TEXTURE_SWIZZLE_B, and TEXTURE_SWIZZLE_A, are applied 132 after the swizzling described in Table 3.20 (p. 186). The swizzle 133 parameter TEXTURE_SWIZZLE_R affects the first component of Cs as: 134 135 if (TEXTURE_SWIZZLE_R == RED) { 136 Cs'[0] = Cs[0]; 137 } else if (TEXTURE_SWIZZLE_R == GREEN) { 138 Cs'[0] = Cs[1]; 139 } else if (TEXTURE_SWIZZLE_R == BLUE) { 140 Cs'[0] = Cs[2]; 141 } else if (TEXTURE_SWIZZLE_R == ALPHA) { 142 Cs'[0] = As; 143 } else if (TEXTURE_SWIZZLE_R == ZERO) { 144 Cs'[0] = 0; 145 } else if (TEXTURE_SWIZZLE_R == ONE) { 146 Cs'[0] = 1; // float or int depending on texture component type 147 } 148 149 and similarly for Cs'[1], Cs'[2], and As'. 150 151 Modify Section 3.11.2 (Shader Execution), p. 197: 152 153 Texture Access 154 155 ...and converts it to a texture source color Cs according to table 156 3.20 (section 3.8.13), followed by application of the texture swizzle 157 as described in section 3.8.13. The GL returns a four-component 158 vector (Rs,Gs,Bs,As) to the fragment shader... 159 160Additions to the AGL/EGL/GLX/WGL Specifications 161 162 None 163 164Errors 165 166 The error INVALID_OPERATION is generated if TexParameteri, 167 TexParameterf, TexParameteriv, or TexParameterfv, parameter <pname> 168 is TEXTURE_SWIZZLE_R, TEXTURE_SWIZZLE_G, TEXTURE_SWIZZLE_B, 169 or TEXTURE_SWIZZLE_A, and <param> is not RED, GREEN, BLUE, ALPHA, 170 ZERO, or ONE. 171 172 The error INVALID_OPERATION is generated if TexParameteriv, or 173 TexParameterfv, parameter <pname> TEXTURE_SWIZZLE_RGBA, and the four 174 consecutive values pointed to by <param> are not all RED, GREEN, BLUE, 175 ALPHA, ZERO, or ONE. 176 177New State 178 179 Changes to table 6.16, p. 277 (Texture, state per texture object) 180 181 Initial 182 Get Value Type Get Command Value Description Sec. Attribute 183 --------- ---- ----------- ------- ----------- ---- --------- 184 TEXTURE_SWIZZLE_R Z GetTexParameter RED Red 3.8.4 texture 185 component swizzle 186 TEXTURE_SWIZZLE_G Z GetTexParameter GREEN Green 3.8.4 texture 187 component swizzle 188 TEXTURE_SWIZZLE_B Z GetTexParameter BLUE Blue 3.8.4 texture 189 component swizzle 190 TEXTURE_SWIZZLE_A Z GetTexParameter ALPHA Alpha 3.8.4 texture 191 component swizzle 192 193Issues 194 195 1) Why not add more new formats instead? 196 197 RESOLVED: Adding new formats is more implementation burden than 198 one might expect. New formats need to be added to the pixel path, 199 must be considered for FBO support, etc.. This extension avoids 200 those issues by solely affecting the result of a texture fetch. 201 202 2) What is the demand for this extension? 203 204 RESOLVED: There are several independent demands for this, 205 including: 206 - OpenGL 3.0 deprecated support for ALPHA, LUMINANCE, 207 LUMINANCE_ALPHA, and INTENSITY formats. This extension provides 208 a simple porting path for legacy applications that used these 209 formats. 210 211 - There have been specific requests for (1,1,1,a), or "white alpha" 212 formats that allow a "decal" texture to be used in the same shader 213 as an RGBA texture. This can be accomplished with an OpenGL 2.1 214 ALPHA texture by doing 215 216 TexParameteri(target, TEXTURE_SWIZZLE_R, ONE); 217 TexParameteri(target, TEXTURE_SWIZZLE_G, ONE); 218 TexParameteri(target, TEXTURE_SWIZZLE_B, ONE); 219 // TEXTURE_SWIZZLE_A is already ALPHA 220 or equivalently 221 GLint swiz[4] = {ONE, ONE, ONE, ALPHA}; 222 TexParameteriv(target, TEXTURE_SWIZZLE_RGBA, swiz); 223 224 or in OpenGL 3.0 "preview" contexts where ALPHA internal formats 225 are deprecated by using a RED texture: 226 TexParameteri(target, TEXTURE_SWIZZLE_R, ONE); 227 TexParameteri(target, TEXTURE_SWIZZLE_G, ONE); 228 TexParameteri(target, TEXTURE_SWIZZLE_B, ONE); 229 TexParameteri(target, TEXTURE_SWIZZLE_A, RED); 230 or equivalently 231 GLint swiz[4] = {ONE, ONE, ONE, RED}; 232 TexParameteriv(target, TEXTURE_SWIZZLE_RGBA, swiz); 233 234 - This functionality is available on Sony PlayStation 3 and can 235 simplify porting those applications to OpenGL. 236 237 3) What names should be used for the components, in both the "source" 238 (<param>) and "destination" (<pname>) enums? RGBA? XYZW? 0123? 239 240 RESOLVED: RGBA for both source and destination. 0123 could cause 241 confusion with ZERO and ONE. RGBA is a natural choice for source, 242 because the spec describes the values returned by textures as "Color" 243 and "Alpha." There's no particular precedent for destination to be 244 XYZW as this is still part of texture and not the shader, so RGBA 245 it is. 246 247 4) How does this interact with depth component textures? 248 249 RESOLVED: The swizzle is applied after the DEPTH_TEXTURE_MODE. This 250 naturally falls out of specifying the swizzle in terms of Table 3.20. 251 252 5) How does this interact with sRGB? 253 254 RESOLVED: The swizzle is applied after sRGB conversion. 255 256 6) How does this interact with NV_register_combiners, 257 NV_texture_shader, and other old "shading" extensions that 258 predate NV/ARB_fragment_program and define their own "interesting" 259 swizzles? 260 261 RESOLVED: Undefined. Core fixed-function shading (texture_env/combine) 262 are fully supported, but old proprietary "configurable shading" 263 extensions are not. 264 265 7) How does the swizzle interact with the fixed-function texture 266 environment referencing the base format? 267 268 RESOLVED: Note that, by virtue of being defined in terms of Table 3.20, 269 the swizzling occurs *before* the texture environment functions 270 (Table 3.21 and 3.22) are applied. So if you used the first example 271 under Issue (2) with fixed-function, the primary color would "pass 272 through" because the ALPHA base format environment function would 273 still apply. In order to effectively swizzle all four components, an 274 INTENSITY format would give the desired result with the same storage 275 requirements. 276 277Revision History 278 279 Revision 1, 2008/08/21 280 - Initial draft 281 Revision 2, 2009/01/28 282 - Add edits to fragment/vertex shader sections to clarify that the 283 swizzle is applied in both. 284 Revision 3, 2009/12/07 285 - Rename EXT->ARB 286