Name ARB_shader_precision Name Strings GL_ARB_shader_precision Contact John Kessenich ( john.kessenich 'at' intel.com ) Contributors Bill Licea-Kane, AMD Chris Dodd, Nvidia Jeff Bolz, Nvidia Pat Brown, Nvidia Piers Daniell, Nvidia Ian Romanick, Intel Daniel Koch, Transgaming Frank ??, Qualcomm Jeremy Sandmel, Apple Jeff Daniels Greg Roth, Nvidia Notice Copyright (c) 2010-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 June 9, 2010. Approved by the Khronos Board of Promoters on July 23, 2010. Version Last Modified Date: 2010-04-29 Author Revision: 6.0 $Date$ $Revision$ Number ARB Extension #98 Dependencies This extension is written against OpenGL 4.0. OpenGL 4.0 is required. Overview This extension more clearly restricts the precision requirements of implementations of the GLSL specification. These include precision of arithmetic operations (operators '+', '/', ...), transcendentals (log, exp, pow, reciprocal sqrt, ...), when NaNs (not a number) and INFs (infinities) will be supported and generated, and denorm flushing behavior. Trigonometric built-ins and some other categories of built-ins are not addressed. IP Status No known IP claims. New Procedures and Functions None. New Types None. New Tokens None, unless we add switches. Additions to the OpenGL Shading Language 4.00 Specification Including the following line in a shader can be used to control the language features described in the extension: #extension GL_ARB_shader_precision : where is as specified in section 3.3. A new preprocessor #define is added to the OpenGL Shading Language: #define GL_ARB_shader_precision 1 Changes to Section 4.1.4 Floats Keep the first two sentences of the second paragraph: As an input value to one of the processing units, a single-precision or double- precision floating-point variable is expected to match the corresponding IEEE 754 floating-point definition for precision and dynamic range. Floating-point variables within a shader are also encoded according to the IEEE 754 specification for single-precision floating-point values.... Remove the remainder of the paragraph: ...However, it is not required that the precision of internal processing match the IEEE 754 floating- point specification for floating-point operations, but the guidelines for precision established by the OpenGL Graphics System Specification must be met. Similarly, treatment of conditions such as divide by 0 may lead to an unspecified result, but in no case should such a condition lead to the interruption or termination of processing. Generally, there are no signaling NaNs, and operating on NaNs (Not a Number) or infs (positive or negative infinities) gives undefined results. replacing it with the following: ...See section 4.5.1 Range and Precision for more details on precision and usage of NaNs (Not a Number) and Infs (positive or negative infinities). Add to Section 4.5.1 Range and Precision The precision of stored single and double precision floating-point variables is defined by the IEEE 754 standard for 32-bit and 64-bit floating-point numbers. This includes support for NaNs (Not a Number) and Infs (positive or negative infinities). The following rules apply to both single and double precision operations: Dividing by 0 results in the appropriately signed IEEE Inf. Any denormalized value input into a shader or potentially generated by an operation in a shader can be flushed to 0. In general, correct signedness of 0 is not required. The rounding mode cannot be set and is undefined. Support for signaling NaNs is not required and exceptions are never raised. Operations and built-in functions that operate on a NaN are not required to return a NaN as the result. Precisions are expressed in terms of maximum relative error in units of ULP (units in the last place). For single precision operations Operation Precision a+b, a-b, a*b correctly rounded <, =<, ==, >, >= correct result a/b, 1.0/b <= 2.5 ULP a*b+c correctly rounded single operation or sequence of two correctly rounded operations fma() same as a*b+c pow <= 16 ULP exp, exp2 <= 3 ULP log, log2 <= 3 ULP sqrt <= 3 ULP inversesqrt <= 2 ULP conversions correctly rounded Built-in functions defined in the specification with an equation built from the above operations inherit the above errors. These include, for example, the geometric functions, the common functions, and many of the matrix functions. Built-in functions not listed above and not defined as equations of the above have undefined precision. These include, for example, the trigonometric functions and determinant. Double precision operations: TBD. Changes to Section 8.3 Common Functions In the table for intBitsToFloat, uintBitsToFloat, and packDouble2x32, change If an inf or NaN is passed in, it will not signal, and the resulting floating point value is unspecified. To If an inf or NaN is passed in, it will not signal, and the resulting floating point value will be a NaN. Issues 1. Operations like fma(), pow(), etc. might not be as precise as specified. To keep backward compatibility, this implies vendors finding out what precisions they do have. Possibly also either new built-ins or modes are needed to access hardware's ability to deliver the more precise versions of what is found. 2. The specification is currently lacking in edge case behavior. How much of this should refer to existing IEEE and language specifications versus be reproduced here? Revision History Revision 1, johnk, 2010-04-29 - Working Draft Revision 2, johnk, 2010-05-06 - Don't require operations on NaNs to return NaNs. - Change from EXT to ARB.