1Name 2 3 ARB_half_float_pixel 4 5Name Strings 6 7 GL_ARB_half_float_pixel 8 9Contributors 10 11 Pat Brown 12 Jon Leech 13 Rob Mace 14 Brian Paul 15 16Contact 17 18 Dale Kirkland, NVIDIA (dkirkland 'at' nvidia.com) 19 20Notice 21 22 Copyright (c) 2004-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 on October 22, 2004. 38 39Version 40 41 Last Modified Date: October 1, 2004 42 Version: 6 43 44Number 45 46 ARB Extension #40 47 48Dependencies 49 50 This extension is written against the OpenGL 2.0 Specification 51 but will work with the OpenGL 1.5 Specification. 52 53 Based on the NV_half_float extension. 54 55 This extension interacts with ARB_color_buffer_float. 56 57Overview 58 59 This extension introduces a new data type for half-precision (16-bit) 60 floating-point quantities. The floating-point format is very similar 61 to the IEEE single-precision floating-point standard, except that it 62 has only 5 exponent bits and 10 mantissa bits. Half-precision floats 63 are smaller than full precision floats and provide a larger dynamic 64 range than similarly sized normalized scalar data types. 65 66 This extension allows applications to use half-precision floating- 67 point data when specifying pixel data. It extends the existing image 68 specification commands to accept the new data type. 69 70 Floating-point data is clamped to [0, 1] at various places in the 71 GL unless clamping is disabled with the ARB_color_buffer_float 72 extension. 73 74IP Status 75 76 SGI owns US Patent #6,650,327, issued November 18, 2003. SGI 77 believes this patent contains necessary IP for graphics systems 78 implementing floating point (FP) rasterization and FP framebuffer 79 capabilities. 80 81 SGI will not grant the ARB royalty-free use of this IP for use in 82 OpenGL, but will discuss licensing on RAND terms, on an individual 83 basis with companies wishing to use this IP in the context of 84 conformant OpenGL implementations. SGI does not plan to make any 85 special exemption for open source implementations. 86 87 Contact Doug Crisman at SGI Legal for the complete IP disclosure. 88 89Issues 90 91 1. How is this extension different from the NV_half_float extension? 92 93 This extension does not add new commands for specifying half- 94 precision vertex data, and all imaging functions have been listed 95 for supporting the "half" type. 96 97 2. What should the new data type be called? "half"? "hfloat"? 98 99 RESOLVED: half . This convention builds on the convention of 100 using the type "double" to describe double-precision floating- 101 point numbers. Here, "half" will refer to half-precision 102 floating-point numbers. 103 104 Even though the 16-bit float data type is a first-class data type, 105 it is still more problematic than the other types in the sense 106 that no native programming languages support the data type. 107 "hfloat/hf" would have reflected a second-class status better 108 than "half/h". 109 110 Both names are not without conflicting precedents. The name "half" 111 is used to connote 16-bit scalar values on some 32-bit CPU 112 architectures (e.g., PowerPC). The name "hfloat" has been used to 113 describe 128-bit floating-point data on VAX systems. 114 115 3. Should half-precision data be accepted by commands in the imaging 116 subset that accept pixel data? 117 118 RESOLVED: Yes, all functions in the core OpenGL and the imaging 119 subset that accept pixel data accept half-precision data. 120 121 4. Should the special representations NaN, INF, and denormal be 122 supported? 123 124 RESOLVED: Implementation dependent. The spec reflects that Nan 125 and INF produce unspecified results. Denormalized numbers can 126 be treated as a value of 0. 127 128 129New Tokens 130 131 Accepted by the <type> parameter of DrawPixels, ReadPixels, 132 TexImage1D, TexImage2D, TexImage3D, GetTexImage, TexSubImage1D, 133 TexSubImage2D, TexSubImage3D, GetHistogram, GetMinmax, 134 ConvolutionFilter1D, ConvolutionFilter2D, GetConvolutionFilter, 135 SeparableFilter2D, GetSeparableFilter, ColorTable, ColorSubTable, 136 and GetColorTable: 137 138 HALF_FLOAT_ARB 0x140B 139 140Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) 141 142 Add a new Section 2.1.2, (p. 6): 143 144 2.1.2 16-Bit Floating-Point Numbers 145 146 A 16-bit floating-point number has a 1-bit sign (S), a 5-bit 147 exponent (E), and a 10-bit mantissa (M). The value of a 16-bit 148 floating-point number is determined by the following: 149 150 (-1)^S * 0.0, if E == 0 and M == 0, 151 (-1)^S * 2^-14 * (M / 2^10), if E == 0 and M != 0, 152 (-1)^S * 2^(E-15) * (1 + M/2^10), if 0 < E < 31, 153 (-1)^S * INF, if E == 31 and M == 0, or 154 NaN, if E == 31 and M != 0, 155 156 where 157 158 S = floor((N mod 65536) / 32768), 159 E = floor((N mod 32768) / 1024), and 160 M = N mod 1024. 161 162 Implementations are also allowed to use any of the following 163 alternative encodings: 164 165 (-1)^S * 0.0, if E == 0 and M != 0, 166 (-1)^S * 2^(E-15) * (1 + M/2^10), if E == 31 and M == 0, or 167 (-1)^S * 2^(E-15) * (1 + M/2^10), if E == 31 and M != 0, 168 169 Any representable 16-bit floating-point value is legal as input 170 to a GL command that accepts 16-bit floating-point data. The 171 result of providing a value that is not a floating-point number 172 (such as infinity or NaN) to such a command is unspecified, but 173 must not lead to GL interruption or termination. Providing a 174 denormalized number or negative zero to GL must yield predictable 175 results. 176 177 (modify Table 2.2, p. 9) -- add new row 178 179 Minimum 180 GL Type Bit Width Description 181 ------- --------- ----------------------------------- 182 half 16 half-precision floating-point value 183 encoded in an unsigned scalar 184 185 Modify Section 2.14, (Colors and Coloring), p. 59 186 187 (modify Table 2.9, p. 59) Add new row to the table: 188 189 GL Type Conversion 190 ------- ---------- 191 half c 192 193 194Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 195 196 Modify Section 3.6.4, Rasterization of Pixel Rectangles (p. 126) 197 198 (modify Table 3.5, p. 128 -- add new row) 199 200 type Parameter Corresponding Special 201 Token Name GL Data Type Interpretation 202 -------------- ------------- -------------- 203 HALF_FLOAT_ARB half No 204 205 (modify Unpacking, p. 129) Data are taken from host memory as a 206 sequence of signed or unsigned bytes (GL data types byte and ubyte), 207 signed or unsigned integers (GL data types int and uint), or 208 floating-point values (GL data types half and float). 209 210Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 211Operations and the Framebuffer) 212 213 Modify Section 4.3.2, Reading Pixels (p. 219) 214 215 (modify Final Conversion, p. 222) For an index, if the type is not 216 FLOAT or HALF_FLOAT_ARB, final conversion consists of masking the 217 index with the value given in Table 4.6; if the type is FLOAT or 218 HALF_FLOAT_ARB, then the integer index is converted to a GL float 219 or half data value. 220 221 (modify Table 4.7, p. 224 -- add new row) 222 223 type Parameter GL Data Type Component Conversion Formula 224 -------------- ------------ ---------------------------- 225 HALF_FLOAT_ARB half c = f 226 227Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 228 229 None 230 231Additions to Chapter 6 of the OpenGL 2.0 Specification (State and 232State Requests) 233 234 None 235 236Additions to the AGL/GLX/WGL Specifications 237 238 None 239 240GLX Protocol (Modification to the GLX 1.3 Protocol Encoding Specification) 241 242 Modify Appendix A, Pixel Data (p. 148) 243 244 (Modify Table A.1, p. 149 -- add new row for HALF_FLOAT_ARB data) 245 246 type Encoding Protocol Type nbytes 247 ------------- -------- ------------- ------ 248 HALF_FLOAT_ARB 0x140B CARD16 2 249 250Errors 251 252 None 253 254New State 255 256 None 257 258New Implementation Dependent State 259 260 None 261 262Revision History 263 264 Rev. Date Author Changes 265 ---- -------- --------- -------------------------------------------- 266 1 12/15/03 Kirkland Initial version based on the NV_half_float 267 specification. 268 269 2 2/26/04 Kirkland Changed NVIDIA_xxx to NV_xxx. 270 Changed the issue resolution for INF and NaN. 271 272 3 3/11/04 Kirkland Updated language for float16 number handling. 273 Added bit encodings for half values. 274 Added issue dealing with name "half". 275 276 4 7/23/04 Kirkland Added alternative encodings options for 277 float16 format. 278 279 5 9/17/04 Kirkland Updated to reference OpenGL 2.0 spec. 280 281 6 10/1/04 Kirkland Updated IP section. 282