[Mesa-dev] [PATCH mesa 3/7] docs/specs: remove upstreamed spec MESA_shader_integer_functions
Eric Engestrom
eric.engestrom at imgtec.com
Wed Nov 22 17:59:37 UTC 2017
Spec is now available on Khronos:
https://www.khronos.org/registry/OpenGL/extensions/MESA/MESA_shader_integer_functions.txt
Signed-off-by: Eric Engestrom <eric.engestrom at imgtec.com>
---
docs/specs/MESA_shader_integer_functions.txt | 522 ---------------------------
1 file changed, 522 deletions(-)
delete mode 100644 docs/specs/MESA_shader_integer_functions.txt
diff --git a/docs/specs/MESA_shader_integer_functions.txt b/docs/specs/MESA_shader_integer_functions.txt
deleted file mode 100644
index 9fcc9b4c5da012be2a24..00000000000000000000
--- a/docs/specs/MESA_shader_integer_functions.txt
+++ /dev/null
@@ -1,522 +0,0 @@
-Name
-
- MESA_shader_integer_functions
-
-Name Strings
-
- GL_MESA_shader_integer_functions
-
-Contact
-
- Ian Romanick <ian.d.romanick at intel.com>
-
-Contributors
-
- All the contributors of GL_ARB_gpu_shader5
-
-Status
-
- Supported by all GLSL 1.30 capable drivers in Mesa 12.1 and later
-
-Version
-
- Version 3, March 31, 2017
-
-Number
-
- OpenGL Extension #495
-
-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.
-
- GLSL 1.30 (OpenGL) or GLSL ES 3.00 (OpenGL ES) is required.
-
- This extension interacts with ARB_gpu_shader5.
-
- This extension interacts with ARB_gpu_shader_fp64.
-
- This extension interacts with NV_gpu_shader5.
-
-Overview
-
- GL_ARB_gpu_shader5 extends GLSL in a number of useful ways. Much of this
- added functionality requires significant hardware support. There are many
- aspects, however, that can be easily implmented on any GPU with "real"
- integer support (as opposed to simulating integers using floating point
- calculations).
-
- This extension provides a set of new features to the OpenGL Shading
- Language to support capabilities of these GPUs, extending the
- capabilities of version 1.30 of the OpenGL Shading Language and version
- 3.00 of the OpenGL ES Shading Language. Shaders using the new
- functionality provided by this extension should enable this
- functionality via the construct
-
- #extension GL_MESA_shader_integer_functions : require (or enable)
-
- This extension provides a variety of new features for all shader types,
- including:
-
- * support for implicitly converting signed integer types to unsigned
- types, as well as more general implicit conversion and function
- overloading infrastructure to support new data types introduced by
- other extensions;
-
- * new built-in functions supporting:
-
- * splitting a floating-point number into a significand and exponent
- (frexp), or building a floating-point number from a significand and
- exponent (ldexp);
-
- * integer bitfield manipulation, including functions to find the
- position of the most or least significant set bit, count the number
- of one bits, and bitfield insertion, extraction, and reversal;
-
- * extended integer precision math, including add with carry, subtract
- with borrow, and extenended multiplication;
-
- The resulting extension is a strict subset of GL_ARB_gpu_shader5.
-
-IP Status
-
- No known IP claims.
-
-New Procedures and Functions
-
- None
-
-New Tokens
-
- None
-
-Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification
-(OpenGL Operation)
-
- None.
-
-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)
-
- None.
-
-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_MESA_shader_integer_functions : <behavior>
-
- where <behavior> is as specified in section 3.3.
-
- New preprocessor #defines are added to the OpenGL Shading Language:
-
- #define GL_MESA_shader_integer_functions 1
-
-
- 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
- ivec2 uvec2, vec2
- ivec3 uvec3, vec3
- ivec4 uvec4, vec4
-
- uint float
- uvec2 vec2
- uvec3 vec3
- uvec4 vec4
-
- (modify second paragraph of the section) No implicit conversions are
- provided to convert from unsigned to signed integer types or from
- floating-point to integer types. There are no implicit array or structure
- conversions.
-
- (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
- and float. 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.
-
-
- Modify Section 5.9, Expressions, p. 57
-
- (modify bulleted list as follows, adding support for implicit conversion
- between signed and unsigned types)
-
- Expressions in the shading language are built from the following:
-
- * Constants of type bool, int, int64_t, uint, uint64_t, float, all vector
- types, and all matrix types.
-
- ...
-
- * The operator modulus (%) operates on signed or unsigned integer scalars
- or vectors. If the fundamental types of the operands do not match, the
- conversions from Section 4.1.10 "Implicit Conversions" are applied to
- produce matching types. ...
-
-
- Modify Section 6.1, Function Definitions, p. 63
-
- (modify description of overloading, beginning at the top of p. 64)
-
- Function names can be overloaded. The same function name can be used for
- multiple functions, as long as the parameter types differ. If a function
- name is declared twice with the same parameter types, then the return
- types and all qualifiers must also match, and it is the same function
- being declared. For example,
-
- vec4 f(in vec4 x, out vec4 y); // (A)
- vec4 f(in vec4 x, out uvec4 y); // (B) okay, different argument type
- vec4 f(in ivec4 x, out uvec4 y); // (C) okay, different argument type
-
- int f(in vec4 x, out ivec4 y); // error, only return type differs
- vec4 f(in vec4 x, in vec4 y); // error, only qualifier differs
- vec4 f(const in vec4 x, out vec4 y); // error, only qualifier differs
-
- When function calls are resolved, an exact type match for all the
- arguments is sought. If an exact match is found, all other functions are
- ignored, and the exact match is used. If no exact match is found, then
- the implicit conversions in Section 4.1.10 (Implicit Conversions) will be
- applied to find a match. Mismatched types on input parameters (in or
- inout or default) must have a conversion from the calling argument type
- to the formal parameter type. Mismatched types on output parameters (out
- or inout) must have a conversion from the formal parameter type to the
- calling argument type.
-
- If implicit conversions can be used to find more than one matching
- function, a single best-matching function is sought. To determine a best
- match, the conversions between calling argument and formal parameter
- types are compared for each function argument and pair of matching
- functions. After these comparisons are performed, each pair of matching
- functions are compared. A function definition A is considered a better
- match than function definition B if:
-
- * for at least one function argument, the conversion for that argument
- in A is better than the corresponding conversion in B; and
-
- * there is no function argument for which the conversion in B is better
- than the corresponding conversion in A.
-
- If a single function definition is considered a better match than every
- other matching function definition, it will be used. Otherwise, a
- semantic error occurs and the shader will fail to compile.
-
- To determine whether the conversion for a single argument in one match is
- better than that for another match, the following rules are applied, in
- order:
-
- 1. An exact match is better than a match involving any implicit
- conversion.
-
- 2. A match involving an implicit conversion from float to double is
- better than a match involving any other implicit conversion.
-
- 3. A match involving an implicit conversion from either int or uint to
- float is better than a match involving an implicit conversion from
- either int or uint to double.
-
- If none of the rules above apply to a particular pair of conversions,
- neither conversion is considered better than the other.
-
- For the function prototypes (A), (B), and (C) above, the following
- examples show how the rules apply to different sets of calling argument
- types:
-
- f(vec4, vec4); // exact match of vec4 f(in vec4 x, out vec4 y)
- f(vec4, uvec4); // exact match of vec4 f(in vec4 x, out ivec4 y)
- f(vec4, ivec4); // matched to vec4 f(in vec4 x, out vec4 y)
- // (C) not relevant, can't convert vec4 to
- // ivec4. (A) better than (B) for 2nd
- // argument (rule 2), same on first argument.
- f(ivec4, vec4); // NOT matched. All three match by implicit
- // conversion. (C) is better than (A) and (B)
- // on the first argument. (A) is better than
- // (B) and (C).
-
-
- Modify Section 8.3, Common Functions, p. 84
-
- (add support for single-precision frexp and ldexp functions)
-
- Syntax:
-
- genType frexp(genType x, out genIType exp);
- genType ldexp(genType x, in genIType exp);
-
- The function frexp() splits each single-precision floating-point number in
- <x> into a 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 single-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 single-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 support for new integer built-in functions)
-
- Syntax:
-
- genIType bitfieldExtract(genIType value, int offset, int bits);
- genUType bitfieldExtract(genUType value, int offset, int bits);
-
- genIType bitfieldInsert(genIType base, genIType insert, int offset,
- int bits);
- genUType bitfieldInsert(genUType base, genUType insert, int offset,
- int bits);
-
- genIType bitfieldReverse(genIType value);
- genUType bitfieldReverse(genUType value);
-
- genIType bitCount(genIType value);
- genIType bitCount(genUType value);
-
- genIType findLSB(genIType value);
- genIType findLSB(genUType value);
-
- genIType findMSB(genIType value);
- genIType findMSB(genUType value);
-
- The function bitfieldExtract() extracts bits <offset> through
- <offset>+<bits>-1 from each component in <value>, returning them in the
- least significant bits of corresponding component of the result. For
- unsigned data types, the most significant bits of the result will be set
- to zero. For signed data types, the most significant bits will be set to
- the value of bit <offset>+<base>-1. If <bits> is zero, the result will be
- zero. The result will be undefined if <offset> or <bits> is negative, or
- if the sum of <offset> and <bits> is greater than the number of bits used
- to store the operand. Note that for vector versions of bitfieldExtract(),
- a single pair of <offset> and <bits> values is shared for all components.
-
- The function bitfieldInsert() inserts the <bits> least significant bits of
- each component of <insert> into the corresponding component of <base>.
- The result will have bits numbered <offset> through <offset>+<bits>-1
- taken from bits 0 through <bits>-1 of <insert>, and all other bits taken
- directly from the corresponding bits of <base>. If <bits> is zero, the
- result will simply be <base>. The result will be undefined if <offset> or
- <bits> is negative, or if the sum of <offset> and <bits> is greater than
- the number of bits used to store the operand. Note that for vector
- versions of bitfieldInsert(), a single pair of <offset> and <bits> values
- is shared for all components.
-
- The function bitfieldReverse() reverses the bits of <value>. The bit
- numbered <n> of the result will be taken from bit (<bits>-1)-<n> of
- <value>, where <bits> is the total number of bits used to represent
- <value>.
-
- The function bitCount() returns the number of one bits in the binary
- representation of <value>.
-
- The function findLSB() returns the bit number of the least significant one
- bit in the binary representation of <value>. If <value> is zero, -1 will
- be returned.
-
- The function findMSB() returns the bit number of the most significant bit
- in the binary representation of <value>. For positive integers, the
- result will be the bit number of the most significant one bit. For
- negative integers, the result will be the bit number of the most
- significant zero bit. For a <value> of zero or negative one, -1 will be
- returned.
-
-
- (support for unsigned integer add/subtract with carry-out)
-
- Syntax:
-
- genUType uaddCarry(genUType x, genUType y, out genUType carry);
- genUType usubBorrow(genUType x, genUType y, out genUType borrow);
-
- The function uaddCarry() adds 32-bit unsigned integers or vectors <x> and
- <y>, returning the sum modulo 2^32. The value <carry> is set to zero if
- the sum was less than 2^32, or one otherwise.
-
- The function usubBorrow() subtracts the 32-bit unsigned integer or vector
- <y> from <x>, returning the difference if non-negative or 2^32 plus the
- difference, otherwise. The value <borrow> is set to zero if x >= y, or
- one otherwise.
-
-
- (support for signed and unsigned multiplies, with 32-bit inputs and a
- 64-bit result spanning two 32-bit outputs)
-
- Syntax:
-
- void umulExtended(genUType x, genUType y, out genUType msb,
- out genUType lsb);
- void imulExtended(genIType x, genIType y, out genIType msb,
- out genIType lsb);
-
- The functions umulExtended() and imulExtended() multiply 32-bit unsigned
- or signed integers or vectors <x> and <y>, producing a 64-bit result. The
- 32 least significant bits are returned in <lsb>; the 32 most significant
- bits are returned in <msb>.
-
-
-GLX Protocol
-
- None.
-
-Dependencies on ARB_gpu_shader_fp64
-
- This extension, ARB_gpu_shader_fp64, and NV_gpu_shader5 all modify the set
- of implicit conversions supported in the OpenGL Shading Language. If more
- than one of these extensions is supported, an expression of one type may
- be converted to another type if that conversion is allowed by any of these
- specifications.
-
- If ARB_gpu_shader_fp64 or a similar extension introducing new data types
- is not supported, the function overloading rule in the GLSL specification
- preferring promotion an input parameters to smaller type to a larger type
- is never applicable, as all data types are of the same size. That rule
- and the example referring to "double" should be removed.
-
-
-Dependencies on NV_gpu_shader5
-
- This extension, ARB_gpu_shader_fp64, and NV_gpu_shader5 all modify the set
- of implicit conversions supported in the OpenGL Shading Language. If more
- than one of these extensions is supported, an expression of one type may
- be converted to another type if that conversion is allowed by any of these
- specifications.
-
- If NV_gpu_shader5 is supported, integer data types are supported with four
- different precisions (8-, 16, 32-, and 64-bit) and floating-point data
- types are supported with three different precisions (16-, 32-, and
- 64-bit). The extension adds the following rule for output parameters,
- which is similar to the one present in this extension for input
- parameters:
-
- 5. If the formal parameters in both matches are output parameters, a
- conversion from a type with a larger number of bits per component is
- better than a conversion from a type with a smaller number of bits
- per component. For example, a conversion from an "int16_t" formal
- parameter type to "int" is better than one from an "int8_t" formal
- parameter type to "int".
-
- Such a rule is not provided in this extension because there is no
- combination of types in this extension and ARB_gpu_shader_fp64 where this
- rule has any effect.
-
-
-Errors
-
- None
-
-
-New State
-
- None
-
-New Implementation Dependent State
-
- None
-
-Issues
-
- (1) What should this extension be called?
-
- UNRESOLVED. This extension borrows from GL_ARB_gpu_shader5, so creating
- some sort of a play on that name would be viable. However, nothing in
- this extension should require SM5 hardware, so such a name would be a
- little misleading and weird.
-
- Since the primary purpose is to add integer related functions from
- GL_ARB_gpu_shader5, call this extension GL_MESA_shader_integer_functions
- for now.
-
- (2) Why is some of the formatting in this extension weird?
-
- RESOLVED: This extension is formatted to minimize the differences (as
- reported by 'diff --side-by-side -W180') with the GL_ARB_gpu_shader5
- specification.
-
- (3) Should ldexp and frexp be included?
-
- RESOLVED: Yes. Few GPUs have native instructions to implement these
- functions. These are generally implemented using existing GLSL built-in
- functions and the other functions provided by this extension.
-
- (4) Should umulExtended and imulExtended be included?
-
- RESOLVED: Yes. These functions should be implementable on any GPU that
- can support the rest of this extension, but the implementation may be
- complex. The implementation on a GPU that only supports 32bit x 32bit =
- 32bit multiplication would be quite expensive. However, many GPUs
- (including OpenGL 4.0 GPUs that already support this function) have a
- 32bit x 16bit = 48bit multiplier. The implementation there is only
- trivially more expensive than regular 32bit multiplication.
-
- (5) Should the pack and unpack functions be included?
-
- RESOLVED: No. These functions are already available via
- GL_ARB_shading_language_packing.
-
- (6) Should the "BitsTo" functions be included?
-
- RESOLVED: No. These functions are already available via
- GL_ARB_shader_bit_encoding.
-
-Revision History
-
- Rev. Date Author Changes
- ---- ----------- -------- -----------------------------------------
- 3 31-Mar-2017 Jon Leech Add ES support (OpenGL-Registry/issues/3)
- 2 7-Jul-2016 idr Fix typo in #extension line
- 1 20-Jun-2016 idr Initial version based on GL_ARB_gpu_shader5.
--
Cheers,
Eric
More information about the mesa-dev
mailing list