1Name 2 3 EXT_shader_implicit_conversions 4 5Name Strings 6 7 GL_EXT_shader_implicit_conversions 8 9Contact 10 11 Jon Leech (oddhack 'at' sonic.net) 12 Daniel Koch, NVIDIA (dkoch 'at' nvidia.com) 13 14Contributors 15 16 Slawomir Grajewski, Intel 17 Contributors to ARB_gpu_shader5 18 19Notice 20 21 Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at 22 http://www.khronos.org/registry/speccopyright.html 23 24 Portions Copyright (c) 2013-2014 NVIDIA Corporation. 25 26Status 27 28 Complete. 29 30Version 31 32 Last Modified Date: April 1, 2014 33 Revision: 6 34 35Number 36 37 OpenGL ES Extension #179 38 39Dependencies 40 41 OpenGL ES 3.1 and OpenGL ES Shading Language 3.10 are required. 42 43 This specification is written against the OpenGL ES 3.10 Shading 44 Language (March 17, 2014) Specification. 45 46Overview 47 48 This extension provides support for implicitly converting signed integer 49 types to unsigned types, as well as more general implicit conversion and 50 function overloading infrastructure to support new data types introduced by 51 other extensions. 52 53Modifications to The OpenGL ES Shading Language Specification, Version 3.10 54 55 Including the following line in a shader can be used to control the 56 language features described in this extension: 57 58 #extension GL_EXT_shader_implicit_conversions : <behavior> 59 60 where <behavior> is as specified in section 3.4. 61 62 A new preprocessor #define is added to the OpenGL ES Shading Language: 63 64 #define GL_EXT_shader_implicit_conversions 1 65 66 67 Add new section 4.1.10 following section 4.1.9 "Arrays": 68 69 4.1.10 Implicit Conversions 70 71 In some situations, an expression and its type will be implicitly 72 converted to a different type. The following table shows all allowed 73 implicit conversions: 74 75 Can be implicitly 76 Type of expression converted to 77 --------------------- ----------------- 78 int uint, float 79 ivec2 uvec2, vec2 80 ivec3 uvec3, vec3 81 ivec4 uvec4, vec4 82 uint float 83 uvec2 vec2 84 uvec3 vec3 85 uvec4 vec4 86 87 No implicit conversions are provided to convert from unsigned to signed 88 integer types or from floating-point to integer types. There are no 89 implicit array or structure conversions. 90 91 When an implicit conversion is done, it is not a re-interpretation of 92 the expression's bit pattern, but a conversion of its value to an 93 equivalent value in the new type. For example, the integer value -5 will 94 be converted to the floating-point value -5.0. Integer values having 95 more bits of precision than a single-precision floating-point mantissa 96 will lose precision when converted to float. 97 98 When performing implicit conversion for binary operators, there may be 99 multiple data types to which the two operands can be converted. For 100 example, when adding an int value to a uint value, both values can be 101 implicitly converted to uint and float. In such cases, a floating-point 102 type is chosen if either operand has a floating-point type. Otherwise, 103 an unsigned integer type is chosen if either operand has an unsigned 104 integer type. Otherwise, a signed integer type is chosen. If operands 105 can be implicitly converted to multiple data types deriving from the 106 same base data type, the type with the smallest component size is used. 107 The conversions in the table above are done only as indicated by other 108 sections of this specification. 109 110 111 Modify Section 5.9 "Expressions", p. 81: 112 113 (modify the specified items in the bulleted list as follows, adding 114 support for implicit conversion between signed and unsigned types) 115 116 Expressions in the shading language are built from the following: 117 118 * The arithmetic binary operators add (+), subtract (-), multiply (*), 119 and divide (/) operate on integer and floating-point scalars, vectors, 120 and matrices. If the fundamental types in the operands do not match, 121 then the conversions from section 4.1.10 "Implicit Conversions" are 122 applied to create matching types. All arithmetic binary operators ... 123 124 * The operator modulus (%) operates on signed or unsigned integer 125 scalars or integer vectors. If the fundamental types of the operands 126 do not match, the conversions from Section &4.1.10 "Implicit 127 Conversions" are applied to produce matching types. The operands 128 cannot be vectors of differing size ... 129 130 * The relational operators greater than (>), less than (<), greater than 131 or equal (>=), and less than or equal (<=) operate only on scalar 132 integer and scalar floating-point expressions. The result is scalar 133 Boolean. Either the operands' types must match, or the conversions 134 from section 4.1.10 "Implicit Conversions" will be applied to obtain 135 matching types. To do component-wise relational comparisons ... 136 137 * The equality operators equal (==), and not equal (!=) operate on all 138 types. They result in a scalar Boolean. If the operand types do not 139 match, then there must be a conversion from section 4.1.10 "Implicit 140 Conversions" applied to one operand that can make them match, in which 141 case this conversion is done. For vectors, matrices, structures, ... 142 143 * The ternary selection operator (?:). It operates on three expressions 144 (exp1 ? exp2 : exp3). This operator evaluates the first expression, 145 which must result in a scalar Boolean. If the result is true, it 146 selects to evaluate the second expression, otherwise it selects to 147 evaluate the third expression. Only one of the second and third 148 expressions is evaluated. The second and third expressions can be any 149 type, as long their types match, or there is a conversion in section 150 4.1.10 "Implicit Conversions" that can be applied to one of the 151 expressions to make their types match. This resulting matching type is 152 the type of the entire expression. 153 154 155 Modify Section 6.1, Function Definitions, p. 88 156 157 (modify description of overloading) 158 159 Function names can be overloaded. The same function name can be used for 160 multiple functions, as long as the parameter types differ. If a function 161 name is declared twice with the same parameter types, then the return 162 types and all qualifiers must also match, and it is the same function 163 being declared. For example, 164 165 vec4 f(in vec4 x, out vec4 y); // (A) 166 vec4 f(in vec4 x, out uvec4 y); // (B) okay, different argument type 167 vec4 f(in ivec4 x, out uvec4 y); // (C) okay, different argument type 168 169 int f(in vec4 x, out ivec4 y); // error, only return type differs 170 vec4 f(in vec4 x, in vec4 y); // error, only qualifier differs 171 vec4 f(const in vec4 x, out vec4 y); // error, only qualifier differs 172 173 When function calls are resolved, an exact type match for all the 174 arguments is sought. If an exact match is found, all other functions are 175 ignored, and the exact match is used. If no exact match is found, then 176 the implicit conversions in section 4.1.10 (Implicit Conversions) will 177 be applied to find a match. Mismatched types on input parameters ("in" 178 or default) must have a conversion from the calling argument type to the 179 formal parameter type. Mismatched types on output parameters ("out") 180 must have a conversion from the formal parameter type to the calling 181 argument type. 182 183 If implicit conversions can be used to find more than one matching 184 function, a single best-matching function is sought. To determine a best 185 match, the conversions between calling argument and formal parameter 186 types are compared for each function argument and pair of matching 187 functions. After these comparisons are performed, each pair of matching 188 functions are compared. A function definition A is considered a better 189 match than function definition B if: 190 191 * for at least one function argument, the conversion for that argument 192 in A is better than the corresponding conversion in B; and 193 194 * there is no function argument for which the conversion in B is 195 better than the corresponding conversion in A. 196 197 If a single function definition is considered a better match than every 198 other matching function definition, it will be used. Otherwise, a 199 compile-time semantic error for an ambiguous overloaded function call 200 occurs. 201 202 To determine whether the conversion for a single argument in one match 203 is better than that for another match, the rule that an exact match is 204 better than a match involving any implicit conversion is used. 205 206 If this rule does not apply to a particular pair of conversions, 207 neither conversion is considered better than the other. 208 209 For the function prototypes (A), (B), and (C) above, the following 210 examples show how the rules apply to different sets of calling argument 211 types: 212 213 f(vec4, vec4); // exact match of vec4 f(in vec4 x, out vec4 y) 214 f(vec4, uvec4); // exact match of vec4 f(in vec4 x, out ivec4 y) 215 f(ivec4, vec4); // NOT matched. All three match by implicit 216 // conversion. (C) is better than (A) and (B) 217 // on the first argument. (A) is better than 218 // (B) and (C). 219 220 User-defined functions can have multiple ... 221 222 223New Implementation Dependent State 224 225 None. 226 227Issues 228 229 Note: These issues apply specifically to the definition of the 230 EXT_shader_implicit_conversions specification, which is based on the 231 OpenGL extension ARB_gpu_shader5 as updated in OpenGL 4.x. Resolved issues 232 from ARB_gpu_shader5 have been removed, but some remain applicable to this 233 extension. ARB_gpu_shader5 can be found in the OpenGL Registry. 234 235 (1) What functionality was removed relative to ARB_gpu_shader5? 236 237 - everything unrelated to implicit conversions and function overloading. 238 - Interactions with features not supported by the underlying 239 ES 3.1 API and Shading Language, including: 240 * interactions with ARB_gpu_shader_fp64 and NV_gpu_shader, including 241 support for double-precision in implicit conversions and function 242 overload resolution 243 * shading language function overloading rules involving the type 244 double 245 246 (2) What functionality was changed and added relative to 247 ARB_gpu_shader5? 248 249 None. 250 251 (3) Are the function overloading rules and examples correct? 252 253 RESOLVED. Rules 2 and 3 as given in the GLSL 4.40 specification do not 254 apply to ESSL, because there are no double types. There is a bug in the 255 example 256 257 f(vec4, ivec4); // matched to vec4 f(in vec4 x, out vec4 y) 258 // (A) better than (B) for 2nd argument 259 // argument (rule 2), same on first argument. 260 261 both because this example is incorrect WRT the overloading rules 262 starting with GLSL 4.00.4, and because the overloading rules in ESSL are 263 simpler. This example has been removed (see bug 11178). 264 265Revision History 266 267 Revision 1, 2013/11/20 (Daniel Koch) 268 - Initial version extracted from EXT_gpu_shader5 rev 2. 269 270 Revision 2, 2013/11/21 (Jon Leech) 271 - Resolve function overloading issue 7, per bug 11178. 272 273 Revision 3, 2013/12/18 (Daniel Koch) 274 - minor cleanup 275 276 Revision 4, 2014/03/10 (Jon Leech) 277 - Rebase on OpenGL ES 3.1 and change suffix to EXT. 278 279 Revision 5, 2014/03/26 (Jon Leech) 280 - Sync with released ES 3.1 specs. 281 282 Revision 6, 2014/04/01 (Daniel Koch) 283 - update contributors 284