1Name 2 3 ARB_shading_language_packing 4 5Name Strings 6 7 GL_ARB_shading_language_packing 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Contributors 14 15 Barthold Lichtenbelt, NVIDIA 16 Chris Dodd, NVIDIA 17 Daniel Koch, Transgaming 18 Eric Werness, NVIDIA 19 Greg Roth, NVIDIA 20 Jeff Bolz, NVIDIA 21 Piers Daniell, NVIDIA 22 23Notice 24 25 Copyright (c) 2011-2013 The Khronos Group Inc. Copyright terms at 26 http://www.khronos.org/registry/speccopyright.html 27 28Specification Update Policy 29 30 Khronos-approved extension specifications are updated in response to 31 issues and bugs prioritized by the Khronos OpenGL Working Group. For 32 extensions which have been promoted to a core Specification, fixes will 33 first appear in the latest version of that core Specification, and will 34 eventually be backported to the extension document. This policy is 35 described in more detail at 36 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 37 38Status 39 40 Complete. Approved by the ARB on 2011/06/20. 41 Approved by the Khronos Promoters on 2011/07/29. 42 43Version 44 45 Last Modified Date: 06/13/2011 46 Revision: 5 47 48Number 49 50 ARB Extension #116 51 52Dependencies 53 54 This extension is written against version 4.1 (revision 09) of the OpenGL 55 Shading Language Specification. 56 57Overview 58 59 This extension provides the GLSL built-in functions to convert a 32-bit 60 unsigned integer holding a pair of 16-bit floating-point values to or from 61 a two-component floating-point vector (vec2). 62 63 This mechanism allows GLSL shaders to read and write 16-bit floating-point 64 encodings (via 32-bit unsigned integers) without introducing a full set of 65 16-bit floating-point data types. 66 67 This extension also adds the GLSL built-in packing functions included in 68 GLSL version 4.00 and the ARB_gpu_shader5 extension which pack and unpack 69 vectors of small fixed-point data types into a larger scalar. By putting 70 these packing functions in this separate extension it allows 71 implementations to provide these functions in hardware that supports them 72 independent of the other ARB_gpu_shader5 features. 73 74 In addition to the packing functions from ARB_gpu_shader5 this extension 75 also adds the missing [un]packSnorm2x16 for completeness. 76 77New Procedures and Functions 78 79 None. 80 81New Tokens 82 83 None. 84 85Modifications to the OpenGL API Specification 86 87 None. 88 89Modifications to The OpenGL Shading Language Specification, Version 4.10 90(Revision 6) 91 92 Including the following line in a shader can be used to control the 93 language features described in this extension: 94 95 #extension GL_ARB_shading_language_packing : <behavior> 96 97 where <behavior> is as specified in section 3.3. 98 99 New preprocessor #defines are added to the OpenGL Shading Language: 100 101 #define GL_ARB_shading_language_packing 1 102 103 Modify Section 8.4, Floating-Point Pack and Unpack Functions 104 105 (add support for general packing functions) 106 107 Syntax: 108 109 uint packUnorm2x16(vec2 v); 110 uint packSnorm2x16(vec2 v); 111 uint packUnorm4x8(vec4 v); 112 uint packSnorm4x8(vec4 v); 113 114 vec2 unpackUnorm2x16(uint v); 115 vec2 unpackSnorm2x16(uint v); 116 vec4 unpackUnorm4x8(uint v); 117 vec4 unpackSnorm4x8(uint v); 118 119 The functions packUnorm2x16(), packSnorm2x16(), packUnorm4x8(), and 120 packSnorm4x8() first convert each component of a two- or four-component 121 vector of normalized floating-point values into 8- or 16-bit integer 122 values. Then, the results are packed into a 32-bit unsigned integer. 123 The first component of the vector will be written to the least 124 significant bits of the output; the last component will be written to 125 the most significant bits. 126 127 The functions unpackUnorm2x16(), unpackSnorm2x16(), unpackUnorm4x8(), 128 and unpackSnorm4x8() first unpacks a single 32-bit unsigned integer into 129 a pair of 16-bit unsigned integers, a pair of 16-bit signed integers, 130 four 8-bit unsigned integers, or four 8-bit signed integers. Then, each 131 component is converted to a normalized floating-point value to generate a 132 two- or four-component vector. The first component of the vector will be 133 extracted from the least significant bits of the input; the last 134 component will be extracted from the most significant bits. 135 136 The conversion between fixed- and normalized floating-point values will be 137 performed as below. 138 139 function conversion 140 --------------- ----------------------------------------------------- 141 packUnorm2x16 fixed_val = round(clamp(float_val, 0, +1) * 65535.0); 142 packSnorm2x16 fixed_val = round(clamp(float_val, -1, +1) * 32767.0); 143 packUnorm4x8 fixed_val = round(clamp(float_val, 0, +1) * 255.0); 144 packSnorm4x8 fixed_val = round(clamp(float_val, -1, +1) * 127.0); 145 unpackUnorm2x16 float_val = fixed_val / 65535.0; 146 unpackSnorm2x16 float_val = clamp(fixed_val / 32767.0, -1, +1); 147 unpackUnorm4x8 float_val = fixed_val / 255.0; 148 unpackSnorm4x8 float_val = clamp(fixed_val / 127.0, -1, +1); 149 150 (add support for 16-bit floating-point packing and unpacking functions) 151 152 Syntax: 153 154 uint packHalf2x16(vec2 v); 155 vec2 unpackHalf2x16(uint v); 156 157 The function packHalf2x16() returns an unsigned integer obtained by 158 converting the components of a two-component floating-point vector to the 159 16-bit floating-point representation found in the OpenGL Specification, 160 and then packing these two 16-bit integers into a 32-bit unsigned integer. 161 The first vector component specifies the 16 least-significant bits of the 162 result; the second component specifies the 16 most-significant bits. 163 164 The function unpackHalf2x16() returns a two-component floating-point 165 vector with components obtained by unpacking a 32-bit unsigned integer into a 166 pair of 16-bit values, interpreting those values as 16-bit floating-point 167 numbers according to the OpenGL Specification, and converting them to 168 32-bit floating-point values. The first component of the vector is 169 obtained from the 16 least-significant bits of v; the second 170 component is obtained from the 16 most-significant bits of v. 171 172GLX Protocol 173 174 None. 175 176Errors 177 178 None. 179 180New State 181 182 None. 183 184New Implementation Dependent State 185 186 None. 187 188Issues 189 190 (1) What should this extension be called? 191 192 RESOLVED: Proposed name is "ARB_shading_language_pack2h" (i.e., pack 193 two half components). 194 195 (2) This functionality is also provided in the NV_gpu_shader5 extension. 196 Why provide a separate extension? 197 198 RESOLVED: This extension provides an additional pack/unpack function on 199 top of those added in GLSL 4.00 without requiring that implementors 200 provide the entirety of NV_gpu_shader5. 201 202 (3) Should we provide a different set of function names to disambiguate 203 from the similar NV_gpu_shader5 versions (which use the "f16vec2" type to 204 represent a pair of fp16 values)? If not, what happens if both this 205 extension and NV_gpu_shader5 are enabled? 206 207 RESOLVED: The functions in this extension will be called "packHalf2x16" 208 and "unpackHalf2x16", which matches the convention of the other 209 pack/unpack functions in GLSL 4.10 closely enough. For example, 210 packUnorm2x16() packs a pair of 16-bit unsigned normalized integers into 211 a 32-bit unsigned integer. 212 213 Had we used the same names as in NV_gpu_shader5, there would be a 214 conflict in the definitions -- the unpacked type here is "vec2", while 215 the unpacked type in NV_gpu_shader5 is "f16vec2" (a two-component vector 216 with explicit 16-bit floating-point types). This conflict poses a 217 problem if both extensions are enabled, and would also arise if future 218 GLSL versions chose to add explicit fp16 types. For the pack functions, 219 an implementation supporting both versions could resolve via function 220 overloading: 221 222 uint packFloat2x16(vec2 v); 223 uint packFloat2x16(f16vec2 v); 224 225 Unfortunately, function overloading is not possible for the return type 226 of the pack function. One could resolve this by providing only: 227 228 f16vec2 unpackFloat2x16(uint v); 229 230 If a shader included code like: 231 232 vec2 unpacked = unpackFloat2x16(uint_value); 233 234 the unpacked value would be returned as f16vec2 data. However, that 235 could be implicitly converted to vec2 if implicit conversions from fp16 236 to fp32 were supported. Such behavior would be consistent with what we 237 did for ARB_gpu_shader_fp64, where fp32 values can be implicitly 238 converted to fp64. 239 240 (4) The packing functions introduced in ARB_gpu_shader5 may be available 241 on hardware that doesn't support the other features from ARB_gpu_shader5. 242 How can an implementation expose those packing functions? 243 244 RESOLVED: Added all the ARB_gpu_shader5 packing functions to revision 245 #5 of this spec; [un]packUnorm2x16, [un]packUnorm4x8 and 246 [un]packSnorm4x8. 247 248 (5) Should we also provide a [un]packSnorm2x16 packing function, which 249 was not included in ARB_gpu_shader5? 250 251 RESOLVED: Yes, these functions have been added for completeness. They 252 have been added to revision #5 of this extension and the extension has 253 been renamed from _pack2h to _packing to encompass all these packing 254 functions. 255 256Revision History 257 258 Rev. Date Author Changes 259 ---- ---------- -------- --------------------------------------------- 260 5 06/13/11 pdaniell Rename the spec to ARB_shading_language_packing 261 and incorporate all the packing functions into 262 this spec, including the [un]packSnorm2x16 263 functions, which have no extension spec. 264 265 4 12/17/10 johnk Put in the pack/unpack section instead of 266 common functions. Change a reference to double. 267 268 3 12/12/2010 pbrown Rename the pack/unpack functions to avoid 269 conflict with NV_gpu_shader5 names (bug 270 6858). Renamed last part of extension name 271 from "pack2f" to "pack2h" to match the 272 function name change. 273 274 2 11/08/2010 pbrown Fix minor errata in the first draft (bug 275 6999). 276 277 1 10/20/2010 pbrown Internal revision. 278