Should GL_EXT_shader_16bit_storage define int -> float constructors?

[johnkslang]

GL_EXT_shader_16bit_storage added constructors like

float16_t(float)

But, did not add

float16_t(int)

Was excluding the latter intentional? Based on the existence of implicit conversions to match function prototypes, one could imagine that it is implied, but it's not really the right reason. Some quotes from the core spec:

In general, constructors are not built-in functions with predetermined prototypes.

and

Constructors can be used to request a data type conversion to change from one scalar type to another scalar type

and

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

The cross-basic-type constructors should either be added to the extension specification and then implemented in glslang (the operators already exist, but don't get created for the above), or glslang should be changed to enforce semantic check in the lack of cross-type constructors.

cc @jeffbolznv

[jeffbolznv]

IIRC it was intentional to omit the cross-type conversions. The SPIR-V 16-bit storage extension only allows FConvert to/from fp16 in very limited cases, and doesn't directly allow conversions to other types. I kind of think this was a mistake in the SPIR-V extension, and the GLSL extension need not limit itself in the same way if we want to change it. But I think that's where the limitation came from and why it was intentional in GLSL.

[pdaniell-nv]

Discussed in the OpenGL/ES meeting on Wednesday. We thought that the spec and glslang should support these conversions to keep things nice and symmetrical. @johnkslang has an action to consider what it would take to allow these conversions on the SPIR-V side, which would make the glslang code easier. If not the conversion could be done by glslang. If we do either of those we'll update the GLSL spec to allow the conversions.