EXT_shader_implicit_conversions

GL_EXT_shader_implicit_conversions

Jon Leech (oddhack 'at' sonic.net)
Daniel Koch, NVIDIA (dkoch 'at' nvidia.com)

Slawomir Grajewski, Intel
Contributors to ARB_gpu_shader5

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.

Complete.

Last Modified Date: April 1, 2014
Revision: 6

OpenGL ES Extension #179

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.

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.

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

None.

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