## NVIDIA DRIVE OS Linux API Reference## 5.1.0.2 Release |

All Data Structures Namespaces Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages

GL_EXT_shader_implicit_conversions

Name EXT_shader_implicit_conversions Name Strings GL_EXT_shader_implicit_conversions Contact Jon Leech (oddhack 'at' sonic.net) Daniel Koch, NVIDIA (dkoch 'at' nvidia.com) Contributors Slawomir Grajewski, Intel Contributors to ARB_gpu_shader5 Notice Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at http://www.khronos.org/registry/speccopyright.html Portions Copyright (c) 2013-2014 NVIDIA Corporation. Status Complete. Version Last Modified Date: April 1, 2014 Revision: 6 Number OpenGL ES Extension #179 Dependencies OpenGL ES 3.1 and OpenGL ES Shading Language 3.10 are required. This specification is written against the OpenGL ES 3.10 Shading Language (March 17, 2014) Specification. Overview This extension provides 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. Modifications to The OpenGL ES Shading Language Specification, Version 3.10 Including the following line in a shader can be used to control the language features described in this extension: #extension GL_EXT_shader_implicit_conversions : <behavior> where <behavior> is as specified in section 3.4. A new preprocessor #define is added to the OpenGL ES Shading Language: #define GL_EXT_shader_implicit_conversions 1 Add new section 4.1.10 following section 4.1.9 "Arrays": 4.1.10 Implicit Conversions In some situations, an expression and its type will be implicitly converted to a different type. The following table shows all allowed 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 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. When an implicit conversion is done, it is not a re-interpretation of the expression's bit pattern, but a conversion of its value to an equivalent value in the new type. For example, the integer value -5 will be converted to the floating-point value -5.0. Integer values having more bits of precision than a single-precision floating-point mantissa will lose precision when converted to float. 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. 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. The conversions in the table above are done only as indicated by other sections of this specification. Modify Section 5.9 "Expressions", p. 81: (modify the specified items in the bulleted list as follows, adding support for implicit conversion between signed and unsigned types) Expressions in the shading language are built from the following: * The arithmetic binary operators add (+), subtract (-), multiply (*), and divide (/) operate on integer and floating-point scalars, vectors, and matrices. If the fundamental types in the operands do not match, then the conversions from section 4.1.10 "Implicit Conversions" are applied to create matching types. All arithmetic binary operators ... * The operator modulus (%) operates on signed or unsigned integer scalars or integer 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. The operands cannot be vectors of differing size ... * The relational operators greater than (>), less than (<), greater than or equal (>=), and less than or equal (<=) operate only on scalar integer and scalar floating-point expressions. The result is scalar Boolean. Either the operands' types must match, or the conversions from section 4.1.10 "Implicit Conversions" will be applied to obtain matching types. To do component-wise relational comparisons ... * The equality operators equal (==), and not equal (!=) operate on all types. They result in a scalar Boolean. If the operand types do not match, then there must be a conversion from section 4.1.10 "Implicit Conversions" applied to one operand that can make them match, in which case this conversion is done. For vectors, matrices, structures, ... * The ternary selection operator (?:). It operates on three expressions (exp1 ? exp2 : exp3). This operator evaluates the first expression, which must result in a scalar Boolean. If the result is true, it selects to evaluate the second expression, otherwise it selects to evaluate the third expression. Only one of the second and third expressions is evaluated. The second and third expressions can be any type, as long their types match, or there is a conversion in section 4.1.10 "Implicit Conversions" that can be applied to one of the expressions to make their types match. This resulting matching type is the type of the entire expression. Modify Section 6.1, Function Definitions, p. 88 (modify description of overloading) 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 default) must have a conversion from the calling argument type to the formal parameter type. Mismatched types on output parameters ("out") 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 compile-time semantic error for an ambiguous overloaded function call occurs. To determine whether the conversion for a single argument in one match is better than that for another match, the rule that an exact match is better than a match involving any implicit conversion is used. If this rule does not 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(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). User-defined functions can have multiple ... New Implementation Dependent State None. Issues Note: These issues apply specifically to the definition of the EXT_shader_implicit_conversions specification, which is based on the OpenGL extension ARB_gpu_shader5 as updated in OpenGL 4.x. Resolved issues from ARB_gpu_shader5 have been removed, but some remain applicable to this extension. ARB_gpu_shader5 can be found in the OpenGL Registry. (1) What functionality was removed relative to ARB_gpu_shader5? - everything unrelated to implicit conversions and function overloading. - Interactions with features not supported by the underlying ES 3.1 API and Shading Language, including: * interactions with ARB_gpu_shader_fp64 and NV_gpu_shader, including support for double-precision in implicit conversions and function overload resolution * shading language function overloading rules involving the type double (2) What functionality was changed and added relative to ARB_gpu_shader5? None. (3) Are the function overloading rules and examples correct? RESOLVED. Rules 2 and 3 as given in the GLSL 4.40 specification do not apply to ESSL, because there are no double types. There is a bug in the example f(vec4, ivec4); // matched to vec4 f(in vec4 x, out vec4 y) // (A) better than (B) for 2nd argument // argument (rule 2), same on first argument. both because this example is incorrect WRT the overloading rules starting with GLSL 4.00.4, and because the overloading rules in ESSL are simpler. This example has been removed (see bug 11178). Revision History Revision 1, 2013/11/20 (Daniel Koch) - Initial version extracted from EXT_gpu_shader5 rev 2. Revision 2, 2013/11/21 (Jon Leech) - Resolve function overloading issue 7, per bug 11178. Revision 3, 2013/12/18 (Daniel Koch) - minor cleanup Revision 4, 2014/03/10 (Jon Leech) - Rebase on OpenGL ES 3.1 and change suffix to EXT. Revision 5, 2014/03/26 (Jon Leech) - Sync with released ES 3.1 specs. Revision 6, 2014/04/01 (Daniel Koch) - update contributors