| 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 : <behavior> |
| |
| where <behavior> 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. |
| |
