Non-uniform dynamic indexing of descriptors is hard to do. I assume this is the case as it is (or was) only an "extension" in Vulkan, and many (or most) Android devices don't support Vulkan 1.2 or Descriptor Indexing. In WebGPU, which is supposed to be a new, modern graphics API does not support it at all. So it must be somewhat troublesome to implement. And yet something like:
if (tex_id == 0)
// SAMPLE FROM DESCRIPTOR/UNIFORM 0
else if (tex_id == 1)
// SAMPLE FROM DESCRIPTOR/UNIFORM 1
or:
switch (tex_id)
case 0: //SAMPLE FROM DESCRIPTOR/UNIFORM 0;
case 1: //SAMPLE FROM DESCRIPTOR/UNIFORM 1;
Is completely fine. What's the difference between these two? And also, why don't graphics APIs, in the scenarios where dynamic non-uniform indexing is not supported by the device, at least emulate something like this? It seems it can be easily emulated using a switch statement or something, except I don't have to write it out.
Non-uniform dynamic indexing of descriptors is hard to do. I assume this is the case as it is (or was) only an "extension" in Vulkan, and many (or most) Android devices don't support Vulkan 1.2 or Descriptor Indexing. In WebGPU, which is supposed to be a new, modern graphics API does not support it at all. So it must be somewhat troublesome to implement. And yet something like:
if (tex_id == 0)
// SAMPLE FROM DESCRIPTOR/UNIFORM 0
else if (tex_id == 1)
// SAMPLE FROM DESCRIPTOR/UNIFORM 1
or:
switch (tex_id)
case 0: //SAMPLE FROM DESCRIPTOR/UNIFORM 0;
case 1: //SAMPLE FROM DESCRIPTOR/UNIFORM 1;
Is completely fine. What's the difference between these two? And also, why don't graphics APIs, in the scenarios where dynamic non-uniform indexing is not supported by the device, at least emulate something like this? It seems it can be easily emulated using a switch statement or something, except I don't have to write it out.
Share Improve this question asked Mar 11 at 19:59 ZebrafishZebrafish 15.1k3 gold badges66 silver badges153 bronze badges2 Answers
Reset to default 4And also, why don't graphics APIs, in the scenarios where dynamic non-uniform indexing is not supported by the device, at least emulate something like this?
Graphics APIs are accelerator APIs, so they often try to steer developers towards the recommend fast path (e.g. assuming uniform descriptor indexing).
The nonuniformEXT()
shader extension does exactly what you suggest, allowing compilers to emit the code needed (if its needed). Most new Android devices support this extension - obviously we lack time-travel to fix the older devices that don't get driver updates ;P
Is completely fine. What's the difference between these two?
How many items do you want to add to your if or switch? With bindless you may have thousands of textures bound, so naïve code like this has scaling issues in the general case.
Why? To support a broad range of hardware.
Older hardware didn't have a need for non-uniform texture sampling, thus they lacked instructions for it. In order to support that hardware, Vulkan defaulted to not supporting non-uniform indexing.
The first version of Vulkan wasn't perfect, but they pretty quickly fixed a lot of the issues. Non-uniform indexing was first added in VK_EXT_descriptor_indexing
, which could work on Vulkan 1.0 with VK_KHR_get_physical_device_properties2
and VK_KHR_maintenance3
, or in Vulkan 1.1, and was fully promoted into Vulkan 1.2 (with hardware support still being optional).
What's the difference between these two?
Well, they're different instructions. Take a look at the x86 mov instruction, it has 35 variants based on the operands. What you've created is a massive control block that switches what instruction is called, passing in immediate value indices each time. Non uniform indexing allows a single instruction to receive a register to use as its index. Newer GPU hardware might be able to jump to the precise instruction in your control block, but older hardware might have to go through every branch.
Is it substantially harder to implement that in hardware? No, but there wasn't a need, so there wasn't an instruction.