(Feature Request) Official Non-32-bit Bitwise Intrinsic Support

[natevm]

We would like to use some of SPIR-V’s bitfield intrinsics, namely OpBitfieldInsert, OpBitfieldUExtract, and OpBitfieldSExtract, OpBitReverse, and OpBitCount on a mix of integer widths (i8, i16, i32, and i64).

Historically, GLSL unofficially supported these operations through intrinsics in that language, but only 32-bit integers were guaranteed to work, and otherwise results were undefined. Still, many IHVs technically supported the non-32 bit variants, either in hardware or through some emulation in the driver.

However, with the current Vulkan spec, we now have the following restriction:

VUID-StandaloneSpirv-Base-04781
The Base operand of any OpBitCount, OpBitReverse, OpBitFieldInsert, OpBitFieldSExtract, or OpBitFieldUExtract instruction must be a 32-bit integer scalar or a vector of 32-bit integers

This restriction is currently always the case, even if SpvCapabilityInt8 / SpvCapabilityInt16 / SpvCapabilityInt64 were requested, and even if a given device technically supports these instructions for non-32-bit integers.

Would it be possible to amend 04781 to allow IHVs that support these intrinsics at a hardware or driver level for non-32-bit types to “opt into” officially supporting these cases? Potentially through a physical device feature?

[natevm]

For some context, this is a followup to issue here: KhronosGroup/SPIRV-Tools#5797 (comment)

Technically, I can ignore the SPIR-V validation layers and depend on the undefined behavior of these intrinsics for non-32-bit types, but it would be more ideal to have an official solution.

@s-perron suggested I submit an issue here.

[DadSchoorse]

It might be worth mentioning FindUMsb, FindSMsb, FindIMsb from GLSL.std.450. They are also 32bit only at the moment, though unlike for the core SPIR-V instruction this limitation is part of the spir-v extended instruction set instead of a Vulkan VUID.

If there is going to be a Vulkan extension to allow non 32bit integers for the core bitwise ops, it might also make sense to update the GLSL.std.450 ops.

[cyanreg]

I ran into this issue too while working on the Vulkan FFv1 encoder in FFmpeg. Its a limitation that shouldn't exist, and prevents us from doing specific optimizations for codecs.