skia / external / github.com / KhronosGroup / OpenGL-Registry / refs/heads/310-issue / . / extensions / ARB / ARB_gpu_shader_fp64.txt

Name | |

ARB_gpu_shader_fp64 | |

Name Strings | |

GL_ARB_gpu_shader_fp64 | |

Contact | |

Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) | |

Contributors | |

Barthold Lichtenbelt, NVIDIA | |

Bill Licea-Kane, AMD | |

Bruce Merry, ARM | |

Chris Dodd, NVIDIA | |

Eric Werness, NVIDIA | |

Graham Sellers, AMD | |

Greg Roth, NVIDIA | |

Jeff Bolz, NVIDIA | |

Nick Haemel, AMD | |

Pierre Boudier, AMD | |

Piers Daniell, 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 at the 2010/01/22 F2F meeting. | |

Approved by the Khronos Board of Promoters on March 10, 2010. | |

Version | |

Last Modified Date: August 27, 2012 | |

NVIDIA Revision: 11 | |

Number | |

ARB Extension #89 | |

Dependencies | |

This extension is written against the OpenGL 3.2 (Compatibility Profile) | |

Specification. | |

This extension is written against version 1.50 (revision 09) of the OpenGL | |

Shading Language Specification. | |

OpenGL 3.2 and GLSL 1.50 are required. | |

This extension interacts with EXT_direct_state_access. | |

This extension interacts with NV_shader_buffer_load. | |

Overview | |

This extension allows GLSL shaders to use double-precision floating-point | |

data types, including vectors and matrices of doubles. Doubles may be | |

used as inputs, outputs, and uniforms. | |

The shading language supports various arithmetic and comparison operators | |

on double-precision scalar, vector, and matrix types, and provides a set | |

of built-in functions including: | |

* square roots and inverse square roots; | |

* fused floating-point multiply-add operations; | |

* splitting a floating-point number into a significand and exponent | |

(frexp), or building a floating-point number from a significand and | |

exponent (ldexp); | |

* absolute value, sign tests, various functions to round to an integer | |

value, modulus, minimum, maximum, clamping, blending two values, step | |

functions, and testing for infinity and NaN values; | |

* packing and unpacking doubles into a pair of 32-bit unsigned integers; | |

* matrix component-wise multiplication, and computation of outer | |

products, transposes, determinants, and inverses; and | |

* vector relational functions. | |

Double-precision versions of angle, trigonometry, and exponential | |

functions are not supported. | |

Implicit conversions are supported from integer and single-precision | |

floating-point values to doubles, and this extension uses the relaxed | |

function overloading rules specified by the ARB_gpu_shader5 extension to | |

resolve ambiguities. | |

This extension provides API functions for specifying double-precision | |

uniforms in the default uniform block, including functions similar to the | |

uniform functions added by EXT_direct_state_access (if supported). | |

This extension provides an "LF" suffix for specifying double-precision | |

constants. Floating-point constants without a suffix in GLSL are treated | |

as single-precision values for backward compatibility with versions not | |

supporting doubles; similar constants are treated as double-precision | |

values in the "C" programming language. | |

This extension does not support interpolation of double-precision values; | |

doubles used as fragment shader inputs must be qualified as "flat". | |

Additionally, this extension does not allow vertex attributes with 64-bit | |

components. That support is added separately by EXT_vertex_attrib_64bit. | |

IP Status | |

No known IP claims. | |

New Procedures and Functions | |

void Uniform1d(int location, double x); | |

void Uniform2d(int location, double x, double y); | |

void Uniform3d(int location, double x, double y, double z); | |

void Uniform4d(int location, double x, double y, double z, double w); | |

void Uniform1dv(int location, sizei count, const double *value); | |

void Uniform2dv(int location, sizei count, const double *value); | |

void Uniform3dv(int location, sizei count, const double *value); | |

void Uniform4dv(int location, sizei count, const double *value); | |

void UniformMatrix2dv(int location, sizei count, boolean transpose, | |

const double *value); | |

void UniformMatrix3dv(int location, sizei count, boolean transpose, | |

const double *value); | |

void UniformMatrix4dv(int location, sizei count, boolean transpose, | |

const double *value); | |

void UniformMatrix2x3dv(int location, sizei count, boolean transpose, | |

const double *value); | |

void UniformMatrix2x4dv(int location, sizei count, boolean transpose, | |

const double *value); | |

void UniformMatrix3x2dv(int location, sizei count, boolean transpose, | |

const double *value); | |

void UniformMatrix3x4dv(int location, sizei count, boolean transpose, | |

const double *value); | |

void UniformMatrix4x2dv(int location, sizei count, boolean transpose, | |

const double *value); | |

void UniformMatrix4x3dv(int location, sizei count, boolean transpose, | |

const double *value); | |

void GetUniformdv(uint program, int location, double *params); | |

(All of the following ProgramUniform* functions are supported if and only | |

if EXT_direct_state_access is supported.) | |

void ProgramUniform1dEXT(uint program, int location, double x); | |

void ProgramUniform2dEXT(uint program, int location, double x, double y); | |

void ProgramUniform3dEXT(uint program, int location, double x, double y, | |

double z); | |

void ProgramUniform4dEXT(uint program, int location, double x, double y, | |

double z, double w); | |

void ProgramUniform1dvEXT(uint program, int location, sizei count, | |

const double *value); | |

void ProgramUniform2dvEXT(uint program, int location, sizei count, | |

const double *value); | |

void ProgramUniform3dvEXT(uint program, int location, sizei count, | |

const double *value); | |

void ProgramUniform4dvEXT(uint program, int location, sizei count, | |

const double *value); | |

void ProgramUniformMatrix2dvEXT(uint program, int location, sizei count, | |

boolean transpose, const double *value); | |

void ProgramUniformMatrix3dvEXT(uint program, int location, sizei count, | |

boolean transpose, const double *value); | |

void ProgramUniformMatrix4dvEXT(uint program, int location, sizei count, | |

boolean transpose, const double *value); | |

void ProgramUniformMatrix2x3dvEXT(uint program, int location, sizei count, | |

boolean transpose, const double *value); | |

void ProgramUniformMatrix2x4dvEXT(uint program, int location, sizei count, | |

boolean transpose, const double *value); | |

void ProgramUniformMatrix3x2dvEXT(uint program, int location, sizei count, | |

boolean transpose, const double *value); | |

void ProgramUniformMatrix3x4dvEXT(uint program, int location, sizei count, | |

boolean transpose, const double *value); | |

void ProgramUniformMatrix4x2dvEXT(uint program, int location, sizei count, | |

boolean transpose, const double *value); | |

void ProgramUniformMatrix4x3dvEXT(uint program, int location, sizei count, | |

boolean transpose, const double *value); | |

New Tokens | |

Returned in the <type> parameter of GetActiveUniform, and | |

GetTransformFeedbackVarying: | |

DOUBLE | |

DOUBLE_VEC2 0x8FFC | |

DOUBLE_VEC3 0x8FFD | |

DOUBLE_VEC4 0x8FFE | |

DOUBLE_MAT2 0x8F46 | |

DOUBLE_MAT3 0x8F47 | |

DOUBLE_MAT4 0x8F48 | |

DOUBLE_MAT2x3 0x8F49 | |

DOUBLE_MAT2x4 0x8F4A | |

DOUBLE_MAT3x2 0x8F4B | |

DOUBLE_MAT3x4 0x8F4C | |

DOUBLE_MAT4x2 0x8F4D | |

DOUBLE_MAT4x3 0x8F4E | |

Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification | |

(OpenGL Operation) | |

Modify Section 2.14.4, Uniform Variables, p. 89 | |

(modify third paragraph, p. 90) ... uniform variable storage for a vertex | |

shader. A uniform matrix with single- or double-precision components will | |

consume no more than 4 * min(r,c) or 8 * min(r,c) uniform components, | |

respectively. A scalar or vector uniform with double-precision components | |

will consume no more than 2<n> components, where <n> is 1 for scalars, and | |

the component count for vectors. A link error is generated ... | |

(add to Table 2.13, p. 96) | |

Type Name Token Keyword | |

-------------------- ---------------- | |

DOUBLE double | |

DOUBLE_VEC2 dvec2 | |

DOUBLE_VEC3 dvec3 | |

DOUBLE_VEC4 dvec4 | |

DOUBLE_MAT2 dmat2 | |

DOUBLE_MAT3 dmat3 | |

DOUBLE_MAT4 dmat4 | |

DOUBLE_MAT2x3 dmat2x3 | |

DOUBLE_MAT2x4 dmat2x4 | |

DOUBLE_MAT3x2 dmat3x2 | |

DOUBLE_MAT3x4 dmat3x4 | |

DOUBLE_MAT4x2 dmat4x2 | |

DOUBLE_MAT4x3 dmat4x3 | |

(modify list of commands at the bottom of p. 99) | |

void Uniform{1,2,3,4}d(int location, T value); | |

void Uniform{1,2,3,4}dv(int location, T value); | |

void UniformMatrix{2,3,4}dv | |

(int location, sizei count, boolean transpose, | |

const double *value); | |

void UniformMatrix{2x3,3x2,2x4,4x2,3x4,4x3}dv | |

(int location, sizei count, boolean transpose, | |

const double *value); | |

(insert after fourth paragraph, p. 100) The Uniform*d{v} commands will | |

load <count> sets of one to four double-precision floating-point values | |

into a uniform location defined as a double, a double vector, or an array | |

of double scalars or vectors. | |

(modify fifth paragraph, p. 100) The UniformMatrix{2,3,4}fv and | |

UniformMatrix{2,3,4}dv commands will load <count> 2x2, 3x3, or 4x4 | |

matrices (corresponding to 2, 3, or 4 in the command name) of single- or | |

double-precision floating-point values, respectively, into ... | |

(replace second bullet on the middle of p. 101, regarding | |

INVALID_OPERATION errors in Uniform* comamnds) | |

* if the type of the uniform declared in the shader does not match the | |

component type and count indicated in the Uniform* command name (where | |

a boolean uniform component type is considered to match any of the | |

Uniform*i{v}, Uniform*ui{v}, or Uniform*f{v} commands), | |

(modify sixth paragraph, p. 100) The UniformMatrix{2x3,3x2,2x4, | |

4x2,3x4,4x3}fv and UniformMatrix{2x3,3x2,2x4,4x2,3x4,4x3}dv commands will | |

load <count> 2x3, 3x2, 2x4, 4x2, 3x4, or 4x3 matrices (corresponding to | |

the numbers in the command name) of single- or double-precision | |

floating-point values, respectively, into ... | |

(modify "Uniform Buffer Object Storage", p. 102, adding a bullet after the | |

last "Members of type", and modifying the subsequent bullet) | |

* Members of type double are extracted from a buffer object by reading a | |

single double-typed value at the specified offset. | |

* Vectors with N elements with basic data types of bool, int, uint, | |

float, or double are extracted as N values in consecutive memory | |

locations beginning at the specified offset, with components stored in | |

order with the first (X) component at the lowest offset. The GL data | |

type used for component extraction is derived according to the rules | |

for scalar members above. | |

Modify Section 2.14.6, Varying Variables, p. 106 | |

(modify third paragraph, p. 107) ... For the purposes of counting input | |

and output components consumed by a shader, variables declared as vectors, | |

matrices, and arrays will all consume multiple components. Each component | |

of variables declared as double-precision floating-point scalars, vectors, | |

or matrices may be counted as consuming two components. | |

(add after the bulleted list, p. 108) For the purposes of counting the | |

total number of components to capture, each component of outputs declared | |

as double-precision floating-point scalars, vectors, or matrices may be | |

counted as consuming two components. | |

Modify Section 2.19, Transform Feedback, p. 130 | |

(add to end of first paragraph, p. 132) ... The results of appending a | |

varying variable to a transform feedback buffer are undefined if any | |

component of that variable would be written at an offset not aligned to | |

the size of the component. | |

Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification | |

(Rasterization) | |

None. | |

Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification | |

(Per-Fragment Operations and the Frame Buffer) | |

None. | |

Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification | |

(Special Functions) | |

None. | |

Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification | |

(State and State Requests) | |

Modify Section 6.1.15, Shader and Program Queries, p. 332 | |

(add to the first list of commands, p. 337) | |

void GetUniformdv(uint program, int location, double *params); | |

Additions to Appendix A of the OpenGL 3.2 (Compatibility Profile) | |

Specification (Invariance) | |

None. | |

Additions to the AGL/GLX/WGL Specifications | |

None. | |

Modifications to The OpenGL Shading Language Specification, Version 1.50 | |

(Revision 09) | |

Including the following line in a shader can be used to control the | |

language features described in this extension: | |

#extension GL_ARB_gpu_shader_fp64 : <behavior> | |

where <behavior> is as specified in section 3.3. | |

New preprocessor #defines are added to the OpenGL Shading Language: | |

#define GL_ARB_gpu_shader_fp64 1 | |

Modify Section 3.6, Keywords, p. 14 | |

(add the following to the list of keywords, p. 14) | |

double dvec2 dvec3 dvec4 | |

dmat2 dmat3 dmat4 | |

dmat2x2 dmat2x3 dmat2x4 | |

dmat3x2 dmat3x3 dmat3x4 | |

dmat4x2 dmat4x3 dmat4x4 | |

(remove "double", "dvec2", "dvec3", and "dvec4" from the list of | |

keywords reserved for future use, p. 15) | |

Modify Section 4.1, Basic Types, p. 17 | |

(add to the basic "Transparent Types" table, pp. 17-18) | |

Types Meaning | |

-------- ---------------------------------------------------------- | |

double a single double-precision floating point scalar | |

dvec2 a two-component double precision floating-point vector | |

dvec3 a three component double precision floating-point vector | |

dvec4 a four component double precision floating-point vector | |

dmat2 a 2x2 double-precision floating-point matrix | |

dmat3 a 3x3 double-precision floating-point matrix | |

dmat4 a 4x4 double-precision floating-point matrix | |

dmat2x2 same as dmat2 | |

dmat2x3 a double-precision matrix with 2 columns and 3 rows | |

dmat2x4 a double-precision matrix with 2 columns and 4 rows | |

dmat3x2 a double-precision matrix with 3 columns and 2 rows | |

dmat3x3 same as dmat3 | |

dmat3x4 a double-precision matrix with 3 columns and 4 rows | |

dmat4x2 a double-precision matrix with 4 columns and 2 rows | |

dmat4x3 a double-precision matrix with 4 columns and 3 rows | |

dmat4x4 same as dmat4 | |

Modify Section 4.1.4, Floats, p. 22 | |

(modify two paragraphs of the section, adding support for doubles) | |

Single- and double-precision floating-point values are available for use | |

in a variety of scalar calculations. Floating-point variables are defined | |

as in the following example: | |

float a, b = 1.5; | |

double c, d = 2.0LF; | |

As an input value to one of the processing units, a single or | |

double-precision floating-point variable is expected to match the IEEE | |

floating-point definition for precision and dynamic range of the | |

corresponding type. It is not required that the precision of internal | |

processing for operands of type "float" match the IEEE floating-point | |

specification for floating-point operations, but the minimum guidelines | |

for precision established by the OpenGL specification must be met. | |

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. | |

(modify the grammar, p. 22, adding "L" suffix) | |

floating-suffix: one of | |

f F lf LF | |

(modify last paragraph, p. 22) ... including before a suffix. When the | |

suffix "lf" or "LF" is present, the literal has type <double>. Otherwise, | |

the literal has type <float>. A leading unary ... | |

Modify Section 4.1.6, Matrices, p. 23 | |

(modify the first paragraph of the section) | |

The OpenGL Shading Language has built-in types for 2Ã—2, 2Ã—3, 2Ã—4, 3Ã—2, | |

3Ã—3, 3Ã—4, 4Ã—2, 4Ã—3, and 4Ã—4 matrices of single- and double-precision | |

floating-point numbers. Matrix types beginning with "mat" have | |

single-precision components; matrix types beginning with "dmat" have | |

double-precision components. The first number in the type is the number | |

of columns, the second is the number of rows. Example matrix declarations: | |

mat2 mat2D; | |

mat3 optMatrix; | |

mat4 view, projection; | |

mat4x4 view; // an alternate way of declaring a mat4 | |

mat3x2 m; // a matrix with 3 columns and 2 rows | |

dmat4 highPrecisionMVP; | |

dmat2x4 skinnyAndTallWithBigComponents; | |

... | |

Modify Section 4.1.10, Implicit Conversions, p. 27 | |

(modify table of implicit conversions) | |

Can be implicitly | |

Type of expression converted to | |

--------------------- ------------------- | |

int uint(*), float, double | |

ivec2 uvec2(*), vec2, dvec2 | |

ivec3 uvec3(*), vec3, dvec3 | |

ivec4 uvec4(*), vec4, dvec4 | |

uint float, double | |

uvec2 vec2, dvec2 | |

uvec3 vec3, dvec3 | |

uvec4 vec4, dvec4 | |

float double | |

vec2 dvec2 | |

vec3 dvec3 | |

vec4 dvec4 | |

mat2 dmat2 | |

mat3 dmat3 | |

mat4 dmat4 | |

mat2x3 dmat2x3 | |

mat2x4 dmat2x4 | |

mat3x2 dmat3x2 | |

mat3x4 dmat3x4 | |

mat4x2 dmat4x2 | |

mat4x3 dmat4x3 | |

(*) if ARB_gpu_shader5 or NV_gpu_shader5 is supported | |

(modify second paragraph of the section) No implicit conversions are | |

provided to convert from unsigned to signed integer types, from | |

floating-point to integer types, or from higher-precision to | |

lower-precision types. There are no implicit array or structure | |

conversions. | |

(add before the final paragraph of the section, p. 27) | |

(insert before the final paragraph of the section) When performing | |

implicit conversion for binary operators, there may be multiple data types | |

to which the two operands can be converted. For example, when adding an | |

int value to a uint value, both values can be implicitly converted to | |

uint, float, and double. In such cases, a floating-point type is chosen | |

if either operand has a floating-point type. Otherwise, an unsigned | |

integer type is chosen if either operand has an unsigned integer type. | |

Otherwise, a signed integer type is chosen. If operands can be implicitly | |

converted to multiple data types deriving from the same base data type, | |

the type with the smallest component size is used. | |

Modify Section 4.3.4, Inputs, p. 31 | |

(modify third paragraph of the section, p. 31) ... Vertex shader inputs | |

can only be single-precision floating-point scalars, vectors, or matrices, | |

or signed and unsigned integers and integer vectors. Vertex shader inputs | |

can also form arrays of these types, but not structures. | |

(modify third paragraph, p. 32, allowing doubles as inputs and disallowing | |

as non-flat fragment inputs) ... Fragment inputs can only be signed and | |

unsigned integers and integer vectors, float, floating-point vectors, | |

double, double-precision vectors, single- or double-precision matrices, or | |

arrays or structures of these. Fragment shader inputs that are signed or | |

unsigned integers, integer vectors, doubles, double-precision vectors, or | |

double-precision matrices must be qualified with the interpolation | |

qualifier flat. | |

Modify Section 4.3.6, Outputs, p. 33 | |

(modify third paragraph of the section, p. 33) They can only be float, | |

double, single- or double-precision floating-point vectors or matrices, | |

signed or unsigned integers or integer vectors, or arrays or structures of | |

any these. | |

(modify last paragraph, p. 33) ... Fragment outputs can only be float, | |

single-precision floating-point vectors, signed or unsigned integers or | |

integer vectors, or arrays of these. ... | |

Modify Section 5.4.1, Conversion and Scalar Constructors, p. 49 | |

(add double to the first list of constructor examples) | |

Converting between scalar types is done as the following prototypes | |

indicate: | |

int(uint) // converts an unsigned integer value to a signed integer | |

int(float) // converts a float value to a signed integer | |

int(double) // converts a double value to a signed integer | |

int(bool) // converts a Boolean value to a signed integer | |

uint(int) // converts a signed integer value to an unsigned integer | |

uint(float) // converts a float value to an unsigned integer | |

uint(double) // converts a double value to an unsigned integer | |

uint(bool) // converts a Boolean value to an unsigned integer | |

float(int) // converts a signed integer value to a float | |

float(uint) // converts an unsigned integer value to a float | |

float(double) // converts a double value to a float | |

float(bool) // converts a Boolean value to a float | |

double(int) // converts a signed integer value to a double | |

double(uint) // converts an unsigned integer value to a double | |

double(float) // converts a float value to a double | |

double(bool) // converts a Boolean value to a double | |

bool(int) // converts a signed integer value to a Boolean | |

bool(uint) // converts an unsigned integer value to a Boolean | |

bool(float) // converts a float value to a Boolean | |

bool(double) // converts a double value to a Boolean | |

(modify second paragraph of the section, p. 49) When constructors are used | |

to convert any floating-point type to an integer, the fractional part of | |

the floating-point value is dropped. ... | |

(modify third paragraph of the section, p. 49) When a constructor is used | |

to convert any integer or floating-point type to bool, 0 and 0.0 are | |

converted to false, and non-zero values are converted to true. When a | |

constructor is used to convert a bool to any integer or floating-point | |

type, false is converted to 0 or 0.0, and true is converted to 1 or 1.0. | |

Modify Section 5.4.2, Vector and Matrix Constructors, p. 50 | |

(modify the last paragraph, p. 50) If the basic type (bool, int, uint, | |

float, or double) of a parameter to a constructor does not match the basic | |

type of the object being constructed, the scalar construction rules | |

(above) are used to convert the parameters. | |

(add to the first group of examples, p. 52) | |

dmat2(dvec2, dvec2) | |

dmat3(dvec3, dvec3, dvec3) | |

dmat4(dvec4, dvec4, dvec4, dvec4) | |

dmat2x4(dvec3, double, // first column | |

double, dvec3) // second column | |

Modify Section 5.9, Expressions, p. 57 | |

(modify bulleted list as follows, adding support for double-precision | |

floating-point types) | |

Expressions in the shading language are built from the following: | |

* Constants of type bool, int, uint, float, double, all vector types and | |

all matrix types. | |

... | |

* The arithmetic binary operators add (+), subtract (-), multiply (*), and | |

divide (/) operate on integer, single-precision floating-point, and | |

double-precision floating-point scalars, vectors, and matrices. If the | |

fundamental type (integer, single-precision floating-point, | |

double-precision floating-point) of the operands do not match, the | |

conversions from Section 4.1.10 "Implicit Conversions" are applied to | |

produce matching types. ... | |

* The arithmetic unary operators negate (-), post- and pre-increment and | |

decrement (-- and ++) operate on integer, single-precision | |

floating-point, or double-precision floating-point values (including | |

vectors and matrices). ... | |

* The relational operators greater than (>), less than (<), and less than | |

or equal (<=) operate only on scalar integer, single-precision | |

floating-point, or double-precision floating-point expressions. The | |

result is scalar Boolean. The fundamental type of the two operands must | |

match, either as specified, or after one of the implicit type | |

conversions specified in Section 4.1.10. ... | |

... | |

Modify Chapter 8, Built-in Functions, p. 81 | |

(add to description of generic types, last paragraph of p. 81) ... Where | |

the input arguments (and corresponding output) can be double, dvec2, | |

dvec3, or dvec4, <genDType> is used as the argument. ... Similarly, <mat> | |

is used for any matrix basic type with single-precision components and | |

<dmat> is used for any matrix basic type with double-precision components. | |

Modify Section 8.2, Exponential Functions, p. 83 | |

(add overloads for double-precision square roots) | |

genDType sqrt(genDType x); | |

genDType inversesqrt(genDType x); | |

Modify Section 8.3, Common Functions, p. 84 | |

(add support for double-precision floating-point multiply-add) | |

Syntax: | |

genDType fma(genDType a, genDType b, genDType c); | |

The function fma() performs a fused double-precision floating-point | |

multiply-add to compute the value a*b+c. The results of fma() may not be | |

identical to evaluating the expression (a*b)+c, because the computation | |

may be performed in a single operation with intermediate precision | |

different from that used to compute a non-fma() expression. | |

The results of fma() are guaranteed to be invariant given fixed inputs | |

<a>, <b>, and <c>, as though the result were taken from a variable | |

declared as "precise". | |

(add support for double-precision frexp and ldexp functions) | |

Syntax: | |

genDType frexp(genDType x, out genIType exp); | |

genDType ldexp(genDType x, in genIType exp); | |

The function frexp() splits each double-precision floating-point number in | |

<x> into its binary significand, a floating-point number in the range | |

[0.5, 1.0), and an integral exponent of two, such that: | |

x = significand * 2 ^ exponent | |

The significand is returned by the function; the exponent is returned in | |

the parameter <exp>. For a floating-point value of zero, the significant | |

and exponent are both zero. For a floating-point value that is an | |

infinity or is not a number, the results of frexp() are undefined. | |

If the input <x> is a vector, this operation is performed in a | |

component-wise manner; the value returned by the function and the value | |

written to <exp> are vectors with the same number of components as <x>. | |

The function ldexp() builds a double-precision floating-point number from | |

each significand component in <x> and the corresponding integral exponent | |

of two in <exp>, returning: | |

significand * 2 ^ exponent | |

If this product is too large to be represented as a double-precision | |

floating-point value, the result is considered undefined. | |

If the input <x> is a vector, this operation is performed in a | |

component-wise manner; the value passed in <exp> and returned by the | |

function are vectors with the same number of components as <x>. | |

(add overloads for double-precision functions) | |

genDType abs(genDType x); | |

genDType sign(genDType x); | |

genDType floor(genDType x); | |

genDType trunc(genDType x); | |

genDType round(genDType x); | |

genDType roundEven(genDType x); | |

genDType ceil(genDType x); | |

genDType fract(genDType x); | |

genDType mod(genDType x, double y); | |

genDType mod(genDType x, genDType y); | |

genDType modf(genDType x, out genDType i); | |

genDType min(genDType x, genDType y); | |

genDType min(genDType x, double y); | |

genDType max(genDType x, genDType y); | |

genDType max(genDType x, double y); | |

genDType clamp(genDType x, genDType minVal, genDType maxVal); | |

genDType clamp(genDType x, double minVal, double maxVal); | |

genDType mix(genDType x, genDType y, genDType a); | |

genDType mix(genDType x, genDType y, double a); | |

genDType mix(genDType x, genDType y, genBType a); | |

genDType step(genDType edge, genDType x); | |

genDType step(double edge, genDType x); | |

genDType smoothstep(genDType edge0, genDType edge1, genDType x); | |

genDType smoothstep(double edge0, double edge1, genDType x); | |

genBType isnan(genDType x); | |

genBType isinf(genDType x); | |

(add support for 64-bit floating-point packing and unpacking functions) | |

Syntax: | |

double packDouble2x32(uvec2 v); | |

uvec2 unpackDouble2x32(double v); | |

The function packDouble2x32() returns a double obtained by packing the | |

components of a two-component unsigned integer vector into a 64-bit value | |

and interpeting its bits according to the IEEE double-precision | |

floating-point representation. The first vector component specifies the | |

32 least significant bits; the second component specifies the 32 most | |

significant bits. | |

The function unpackDouble2x32() returns a two-component unsigned integer | |

vector obtained by interpreting a double using the 64-bit IEEE | |

double-precision floating-point representation and unpacking into two | |

32-bit halves. The first component of the vector contains the 32 least | |

significant bits of the double; the second component consists the 32 most | |

significant bits. | |

Modify Section 8.4, Geometric Functions, p. 87 | |

(add double-precision equivalents for existing geometric functions) | |

double length(genDType x); | |

double distance(genDType p0, genDType p1); | |

double dot(genDType x, genDType y); | |

dvec3 cross(dvec3 x, dvec3 y); | |

genDType normalize(genDType x); | |

genDType faceforward(genDType N, genDType I, genDType Nref); | |

genDType reflect(genDType I, genDType N); | |

genDType refract(genDType I, genDType N, double eta); | |

Modify Section 8.5, Matrix Functions, p. 89 | |

(add double-precision equivalents for existing matrix functions) | |

dmat matrixCompMult(dmat x, dmat y); | |

dmat2 outerProduct(dvec2 c, dvec2 r); | |

dmat3 outerProduct(dvec3 c, dvec3 r); | |

dmat4 outerProduct(dvec4 c, dvec4 r); | |

dmat2x3 outerProduct(dvec3 c, dvec2 r); | |

dmat3x2 outerProduct(dvec2 c, dvec3 r); | |

dmat2x4 outerProduct(dvec4 c, dvec2 r); | |

dmat4x2 outerProduct(dvec2 c, dvec4 r); | |

dmat3x4 outerProduct(dvec4 c, dvec3 r); | |

dmat4x3 outerProduct(dvec3 c, dvec4 r); | |

dmat2 transpose(dmat2 m); | |

dmat3 transpose(dmat3 m); | |

dmat4 transpose(dmat4 m); | |

dmat2x3 transpose(dmat3x2 m); | |

dmat3x2 transpose(dmat2x3 m); | |

dmat2x4 transpose(dmat4x2 m); | |

dmat4x2 transpose(dmat2x4 m); | |

dmat3x4 transpose(dmat4x3 m); | |

dmat4x3 transpose(dmat3x4 m); | |

double determinant(dmat2 m); | |

double determinant(dmat3 m); | |

double determinant(dmat4 m); | |

dmat2 inverse(dmat2 m); | |

dmat3 inverse(dmat3 m); | |

dmat4 inverse(dmat4 m); | |

Modify Section 8.6, Vector Relational Functions, p. 90 | |

(modify the first paragraph, p. 90, adding support for relational | |

functions operating on double precision types) | |

Relational and equality operators (<, <=, >, >=, ==, !=) are defined (or | |

reserved) to operate on scalars and produce scalar Boolean results. For | |

vector results, use the following built-in functions. In the definitions | |

below, the following terms are used as placeholders for all vector types | |

for a given fundamental data type. In all cases, the sizes of the input | |

and return vectors for any particular call must match. | |

placeholder fundamental types | |

----------- ------------------------------------------------ | |

bvec bvec2, bvec3, bvec4 | |

ivec ivec2, ivec3, ivec4 | |

uvec uvec2, uvec3, uvec4 | |

vec vec2, vec3, vec4, dvec2, dvec3, dvec4 | |

Modify Section 9, Shading Language Grammar, p. 92 | |

!!! TBD !!! | |

GLX Protocol | |

!!! TBD | |

Dependencies on ARB_gpu_shader5 | |

If ARB_gpu_shader5 is not supported, the changes to the function | |

overloading rules in the OpenGL Shading Language Specification provided | |

there should included in this extension. | |

Dependencies on NV_gpu_shader5 | |

This extension and NV_gpu_shader5 both provide support for shading | |

language variables with 64-bit components. If both extensions are | |

supported, the various edits describing this new support should be | |

combined. | |

Dependencies on EXT_direct_state_access | |

If EXT_direct_state_access is not supported, references to the | |

ProgramUniform*d*EXT functions should be removed. | |

If EXT_direct_state_access is supported, that specification should be | |

edited as follows: | |

(modify the ProgramUniform* language) | |

The following commands: | |

.... | |

void ProgramUniform{1,2,3,4}dEXT(uint program int location, T value); | |

void ProgramUniform{1,2,3,4}dvEXT (uint program, int location, | |

const T *value); | |

void ProgramUniformMatrix{2,3,4}dvEXT | |

(uint program, int location, sizei count, boolean transpose, | |

const double *value); | |

void ProgramUniformMatrix{2x3,3x2,2x4,4x2,3x4,4x3}dvEXT | |

(uint program, int location, sizei count, boolean transpose, | |

const double *value); | |

operate identically to the corresponding command where "Program" is | |

deleted from the name (and extension suffixes are dropped or updated | |

appropriately) except, rather than updating the currently active program | |

object, these "Program" commands update the program object named by the | |

<program> parameter. ... | |

Dependencies on NV_shader_buffer_load | |

If NV_shader_buffer_load is supported, that specification should be edited | |

as follows: | |

Modify "Section 2.20.X, Shader Memory Access" from NV_shader_buffer_load. | |

(add rules for loads of variables having the new data types from this | |

extension to the list of bullets following "When a shader dereferences a | |

pointer variable") | |

- Data of type "double" are read from or written to memory as one | |

double-typed value at the specified GPU address. | |

Errors | |

None. | |

New State | |

None. | |

New Implementation Dependent State | |

None. | |

Issues | |

(1) How do double-precision types interact with the rules for storing | |

uniforms in a buffer object? | |

RESOLVED: The rules were already written with data types larger and | |

smaller than those in the original GLSL in mind. Single precision | |

floats typically take four bytes; doubles take eight bytes. The larger | |

storage requirement for doubles means a larger alignment requirement; | |

doubles still need to be size-aligned. | |

(2) Should double-precision vertex shader inputs be supported? | |

RESOLVED: Not in this extension. Such support will be added by the | |

EXT_vertex_attrib_64bit extension. | |

(3) Should double-precision fragment shader outputs be supported? | |

RESOLVED: Not in this extension. Note that we don't have | |

double-precision framebuffer formats to accept such values. | |

(4) Should transform feedback be able to capture double-precision | |

components? | |

RESOLVED: Yes. However, undefined behavior will occur unless all | |

components are captured to size-aligned offsets. | |

If any variable captured in transform feedback has double-precision | |

components, the practical requirements for defined behavior are: | |

(a) the offset of the base of a buffer object must be a multiple of | |

eight bytes; | |

(b) the amount of data captured per vertex must be a multiple of eight | |

bytes; and | |

(c) each double-precision variable captured must be aligned to a | |

multiple of eight bytes relative to the beginning of a vertex. | |

If capturing a mix of single- and double-precision components, it might | |

be necessary to use the "gl_SkipComponents1" variable from | |

ARB_transform_feedback3 to force proper alignment. | |

We considered the possibility of adding error checks to throw errors in | |

cases where undefined behavior might occur, but chose not to include | |

such errors. For OpenGL 3.0-style transform feedback, cases (b) and (c) | |

are solely a function of the variables captured could be detected when a | |

program object is linked. (Such an error would be more problematic for | |

transform feedback via NV_transform_feedback, where the set of variables | |

captured can be updated without relinking.) For case (a), the | |

requirement of OpenGL 3.0 is that transform feedback buffer offsets must | |

be a multiple of 4 bytes; enforcing a stricter 8-byte alignment would | |

require either a backward-incompatible change or a Begin-time error to | |

checks the offset of transform feedback buffers against the current | |

program. | |

(5) Should we have double-precision matrix types? We didn't add integer | |

matrices, but integer matrix math is fairly uncommon. | |

RESOLVED: Yes, we will support all matrix sizes in double-precision. | |

We will also provide double-precision equivalents for all matrix | |

operators and built-in matrix functions. | |

(6) What should be done to distinguish between single- and | |

double-precision floating-point constants? | |

RESOLVED: We will use "LF" to identify double-precision floating-point | |

constants. Here, we depart from the C standard. In C, floating-point | |

constants without a suffix are implicitly double-precision and require a | |

"F" suffix to specify a single-precision constant. However, GLSL has | |

historically provided no support for double precision. Changing to C | |

rules would materially affect the behavior of pre-existing shaders that | |

add an #extension line for this extension, since constants with no | |

suffix have meant "float" up to now. Additionally, such a change would | |

likely have required that we introduce implicit conversions from double | |

to float; otherwise, assigning a constant with no suffix to a float | |

would result in a compile-time error. | |

(7) Should we require IEEE 1394-compliant behavior for NaNs and | |

infinities? Denorms? | |

RESOLVED: Following historical precedent in the GLSL and OpenGL APIs | |

not defining special-case floating-point behavior, we chose not to do so | |

in this extension. | |

(8) Should we provide double-precision versions of all the built-ins that | |

take a <genType>, which are currently defined to be floats and | |

floating-point vectors? | |

RESOLVED: We provide double-precision versions of most of the built-in | |

functions supported by GLSL. We opted not to provide double-precision | |

functions for special trigonometry, exponential, derivative, and noise | |

functions. | |

(9) Are double-precision "varyings" (values passed between shader stages) | |

supported by this extension? If so, is double-precision interpolation | |

is supported? | |

RESOLVED: Double-precision shader inputs and outputs are supported, | |

except for vertex shader inputs and fragment shader outputs. | |

Additionally, double-precision vertex shader inputs are provided by the | |

separate extension EXT_vertex_attrib_64bit. No known extension provides | |

double-precision fragment outputs, but that doesn't seem important since | |

OpenGL provides no pixel/texture formats with double-precision | |

components that could reasonably receive such outputs. | |

Interpolation not supported in this extension for double-precision | |

floating-point components. As with integer types in OpenGL 3.0, | |

double-precision floating-point fragment shader inputs must be qualified | |

as "flat". | |

Note that this extension reformulates the spec language requiring "flat" | |

qualifiers, in addition to adding doubles to the list of "flat" types. | |

In GLSL 1.30, the spec applies these requirements to vertex shader | |

outputs but imposes no requirement on fragment inputs. We move this | |

requirement to fragment inputs, since vertex shader outputs may be | |

passed to tessellation or geometry shaders without interpolation, and | |

thus without the need for qualification by "flat". | |

(15) Can the 64-bit uniform APIs be used to load values for uniforms of | |

type "bool", "bvec2", "bvec3", or "bvec4"? | |

RESOLVED: No. OpenGL 2.0 and beyond did allow "bool" variable to be | |

set with Uniform*i* and Uniform*f APIs, and OpenGL 3.0 extended that | |

support to Uniform*ui* for orthogonality. But it seems pointless to | |

extended this capability forward to 64-bit Uniform APIs as well. | |

(19) Should we support any implicit conversion of matrix types, now that | |

we have both "mat4" and "dmat4"? | |

RESOLVED: No. It doesn't seem worth the trouble. | |

Revision History | |

Rev. Date Author Changes | |

---- -------- -------- ----------------------------------------- | |

11 08/27/12 pbrown Clarify that Uniform*d can not be used to load | |

uniforms with boolean types (bug 9345); import | |

issue (15) on the topic from NV_gpu_shader5. | |

10 03/23/10 pbrown Update issues section to include fp64 issues | |

that were left behind in NV_gpu_shader5 when the | |

specs were refactored. | |

9 02/02/10 pbrown Specify that capturing any component at an | |

offset that is not size-aligned results in | |

undefined behavior (bug 5863). | |

8 01/29/10 pbrown Remove shading language and API support for | |

double-precision vertex attributes; moved to the | |

EXT_vertex_attrib_64bit specification (bug | |

5953). Added clarification disallowing | |

double-precision fragment shader outputs. | |

7 01/29/10 pbrown Delete accidental modifications to the language | |

for equal and not equal operators (bug 5904), | |

which already supported all types. | |

6 01/15/10 pbrown Modify the spec rules for counting attributes, | |

input and output components, and components | |

to capture in transform feedback to permit, | |

but not require, double-precision values to | |

require twice as many resources as single- | |

precision equivalents (bug 5855). | |

5 01/14/10 pbrown Minor updates from spec reviews. | |

4 12/10/09 pbrown Functionality updates from spec review: | |

Allow implicit conversion from mat*->dmat*. | |

Rename fmad and [un]packFloat2x32 to fma | |

and [un]packDouble2x32. Add overlooked | |

fp64 versions of geometric functions. | |

3 12/10/09 pbrown Convert from EXT to ARB. | |

2 12/08/09 pbrown Miscellaneous fixes from spec review: Clarified | |

input/output component counting rules, where | |

each fp64 value counts double. General typo | |

fixes and language clarifications. | |

1 pbrown Internal revisions. |