search

KhronosGroup / Vulkan-Docs

The Vulkan API Specification and related tools
Other
2.8k stars 468 forks source link

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

Open natevm opened 1 month ago

natevm commented 1 month ago

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 commented 1 month ago

For some context, this is a followup to issue here: https://github.com/KhronosGroup/SPIRV-Tools/issues/5797#issuecomment-2346501676

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 commented 1 month ago

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.