About int16 requeriments.. about clspv HOT 2 CLOSED

Hey @oscarbg:

VK_KHR_16bit_storage is also required in addition to shaderInt16 for kernels with int16 arguments?

We don't need VK_KHR_16bit_storage as long as shaderInt16 is supported.

can shaderInt16 restriction be avoided by requiring only VK_KHR_16bit_storage for kernels with int16 variables/arguments by "treating it" internally as int32 for operations using it but storing as 16bits using VK_KHR_16bit_storage?

In theory this could work - but it fails on something important that we see in a lot of OpenCL C kernels. A ton of OpenCL C kernels use pointer bitcasts to reinterpret a buffer as another type - something which fundamentally Vulkan SPIR-V does not support. To work around this a huge amount of the effort in this porting effort was in transforming any pointer bitcasts we see in the code into a load/store and a value bitcast instead.

If we could not use the shaderInt16 capability we would be unable to transform code like:

global int* a;
short b = ((global short*)a)[10];

So yes - the compiler could be made to work without the shaderInt16 capability, but we'd be unable to support some of the usecases we have for this code.

from clspv.

Closing in favour of the https://github.com/google/clspv/milestone/1 milestone.

from clspv.