[202y] Should 16-bit types be enabled by default?

[llvm-beanz]

Is your feature request related to a problem? Please describe.
16 bit type support is pretty common these days. Should we enable 16-bit types by default in HLSL 202y?

Describe the solution you'd like
We should consider the pros and cons of enabling 16-bit types by default, and if there are other changes we should make along with 16bit types. One question that comes to mind is should we adjust the size of bool to be 16-bits rather than 32 when 16-bit types are supported?

[Keenuts]

Since Vulkan 1.1, float16 is core for both variables and buffers, but the feature doesn't have to be supported, just understood.
Looks like float16 support for storage is 60% on Android and ~80 on desktop (https://vulkan.gpuinfo.org/displayextensiondetail.php?extension=VK_KHR_16bit_storage)

should we adjust the size of bool to be 16-bits rather than 32 when 16-bit types are supported?

Is this size change only for local variables, or also for interfaces/uniforms/buffers?

[llvm-beanz]

Just to align terminology: from the language specification the object representation is how it is stored in memory, and the value representation is how it might be stored in registers. The object representation can vary by memory space, which accounts for HLSL's different packing rules for constant buffers vs other memory spaces. Generally sizeof(T) returns the size of the object representation in the thread-local memory space.

Ideally the object representation of fundamental data types does not change based on where it is stored or how the data is declared (i.e. the object representation of half is the same whether it is stored in a buffer or variable). The value representation may change, which is the case with bool today.

Today bool has a 32-bit object representation and a 1-bit value representation (any value other than true or false is undefined behavior).

Since Vulkan 1.1, float16 is core for both variables and buffers, but the feature doesn't have to be supported, just understood. Looks like float16 support for storage is 60% on Android and ~80 on desktop (https://vulkan.gpuinfo.org/displayextensiondetail.php?extension=VK_KHR_16bit_storage)

That tracks with my expectation. I think most hardware these days supports float16. Technically storage is probably the only thing that really matters because the operations can be emulated at higher precision and still meet the precision minimums of float16.

should we adjust the size of bool to be 16-bits rather than 32 when 16-bit types are supported?

Is this size change only for local variables, or also for interfaces/uniforms/buffers?

This would be changing the object representation to 16-bits. The more I think about this I don't think we should do it. We really want an 8-bit bool to align with C++. There are things we could do to emulate 8-bit bools (and maybe we should think about those), but changing the size of bool will be disruptive so we should probably only do it once when we can align with C++ on 8-bits.

[Keenuts]

Technically storage is probably the only thing that really matters

That's my main concern for either Float16 or Bool8/Bool1/Bool16, if somebody writes a Texture<bool>, RWStructuredBuffer<bool> or RWStructuredBuffer<half> we wouldn't want the object representation to be something surprising when used on the API side.

It looks like Vulkan supports for VK_FORMAT_R8_UINT (1 component, 8-bit, unsigned) and R16_SFLOAT (1 component, 16-bit, float) support is quite common as long as atomics are not involved.

[devshgraphicsprogramming]

one word of warning, uint16 is ubiquitous, everywhere EXCEPT push constants (even RDNA cards don't support) and groupshared