1Name 2 3 ARB_shader_precision 4 5Name Strings 6 7 GL_ARB_shader_precision 8 9Contact 10 11 John Kessenich ( john.kessenich 'at' intel.com ) 12 13Contributors 14 15 Bill Licea-Kane, AMD 16 Chris Dodd, Nvidia 17 Jeff Bolz, Nvidia 18 Pat Brown, Nvidia 19 Piers Daniell, Nvidia 20 Ian Romanick, Intel 21 Daniel Koch, Transgaming 22 Frank ??, Qualcomm 23 Jeremy Sandmel, Apple 24 Jeff Daniels 25 Greg Roth, Nvidia 26 27Notice 28 29 Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at 30 http://www.khronos.org/registry/speccopyright.html 31 32Specification Update Policy 33 34 Khronos-approved extension specifications are updated in response to 35 issues and bugs prioritized by the Khronos OpenGL Working Group. For 36 extensions which have been promoted to a core Specification, fixes will 37 first appear in the latest version of that core Specification, and will 38 eventually be backported to the extension document. This policy is 39 described in more detail at 40 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 41 42Status 43 44 Complete. Approved by the ARB on June 9, 2010. 45 Approved by the Khronos Board of Promoters on July 23, 2010. 46 47Version 48 49 Last Modified Date: 2010-04-29 50 Author Revision: 6.0 51 $Date$ $Revision$ 52 53Number 54 55 ARB Extension #98 56 57Dependencies 58 59 This extension is written against OpenGL 4.0. 60 61 OpenGL 4.0 is required. 62 63Overview 64 65 This extension more clearly restricts the precision requirements of 66 implementations of the GLSL specification. These include precision of 67 arithmetic operations (operators '+', '/', ...), transcendentals (log, exp, 68 pow, reciprocal sqrt, ...), when NaNs (not a number) and INFs (infinities) will 69 be supported and generated, and denorm flushing behavior. Trigonometric 70 built-ins and some other categories of built-ins are not addressed. 71 72IP Status 73 74 No known IP claims. 75 76New Procedures and Functions 77 78 None. 79 80New Types 81 82 None. 83 84New Tokens 85 86 None, unless we add switches. 87 88Additions to the OpenGL Shading Language 4.00 Specification 89 90 Including the following line in a shader can be used to control the 91 language features described in the extension: 92 93 #extension GL_ARB_shader_precision : <behavior> 94 95 where <behavior> is as specified in section 3.3. 96 97 A new preprocessor #define is added to the OpenGL Shading Language: 98 99 #define GL_ARB_shader_precision 1 100 101Changes to Section 4.1.4 Floats 102 103 Keep the first two sentences of the second paragraph: 104 105 As an input value to one of the processing units, a single-precision or double- 106 precision floating-point variable is expected to match the corresponding IEEE 107 754 floating-point definition for precision and dynamic range. Floating-point 108 variables within a shader are also encoded according to the IEEE 754 109 specification for single-precision floating-point values.... 110 111 Remove the remainder of the paragraph: 112 113 ...However, it is not 114 required that the precision of internal processing match the IEEE 754 floating- 115 point specification for floating-point operations, but the guidelines for 116 precision established by the OpenGL Graphics System Specification must be met. 117 Similarly, treatment of conditions such as divide by 0 may lead to an 118 unspecified result, but in no case should such a condition lead to the 119 interruption or termination of processing. Generally, there are no signaling 120 NaNs, and operating on NaNs (Not a Number) or infs (positive or negative 121 infinities) gives undefined results. 122 123 replacing it with the following: 124 125 ...See section 4.5.1 Range and Precision for more details on precision and 126 usage of NaNs (Not a Number) and Infs (positive or negative infinities). 127 128Add to Section 4.5.1 Range and Precision 129 130 The precision of stored single and double precision floating-point variables is 131 defined by the IEEE 754 standard for 32-bit and 64-bit floating-point numbers. 132 This includes support for NaNs (Not a Number) and Infs (positive or negative 133 infinities). 134 135 The following rules apply to both single and double precision operations: 136 Dividing by 0 results in the appropriately signed IEEE Inf. Any denormalized 137 value input into a shader or potentially generated by an operation in a shader 138 can be flushed to 0. In general, correct signedness of 0 is not required. The 139 rounding mode cannot be set and is undefined. Support for signaling NaNs is 140 not required and exceptions are never raised. Operations and built-in functions 141 that operate on a NaN are not required to return a NaN as the result. 142 143 Precisions are expressed in terms of maximum relative error in units of ULP 144 (units in the last place). 145 146 For single precision operations 147 148 Operation Precision 149 150 a+b, a-b, a*b correctly rounded 151 <, =<, ==, >, >= correct result 152 a/b, 1.0/b <= 2.5 ULP 153 a*b+c correctly rounded single operation or 154 sequence of two correctly rounded operations 155 fma() same as a*b+c 156 pow <= 16 ULP 157 exp, exp2 <= 3 ULP 158 log, log2 <= 3 ULP 159 sqrt <= 3 ULP 160 inversesqrt <= 2 ULP 161 conversions correctly rounded 162 163 Built-in functions defined in the specification with an equation built from the 164 above operations inherit the above errors. These include, for example, the 165 geometric functions, the common functions, and many of the matrix functions. 166 Built-in functions not listed above and not defined as equations of the above 167 have undefined precision. These include, for example, the trigonometric 168 functions and determinant. 169 170 Double precision operations: 171 172 TBD. 173 174Changes to Section 8.3 Common Functions 175 176 In the table for intBitsToFloat, uintBitsToFloat, and packDouble2x32, change 177 178 If an inf or NaN is passed in, it will not signal, and the resulting floating 179 point value is unspecified. 180 181 To 182 183 If an inf or NaN is passed in, it will not signal, and the resulting floating 184 point value will be a NaN. 185 186Issues 187 1881. Operations like fma(), pow(), etc. might not be as precise as specified. To 189keep backward compatibility, this implies vendors finding out what precisions they do 190have. Possibly also either new built-ins or modes are needed to access 191hardware's ability to deliver the more precise versions of what is found. 192 1932. The specification is currently lacking in edge case behavior. How much of this 194should refer to existing IEEE and language specifications versus be reproduced 195here? 196 197Revision History 198 199 Revision 1, johnk, 2010-04-29 200 - Working Draft 201 202 Revision 2, johnk, 2010-05-06 203 - Don't require operations on NaNs to return NaNs. 204 - Change from EXT to ARB. 205 206