You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
VK_DESCRIPTOR_BINDING_PARTIALLY_BOUND_BIT indicates that descriptors in this binding that are not dynamically used need not contain valid descriptors at the time the descriptors are consumed. A descriptor is dynamically used if any shader invocation executes an instruction that performs any memory access using the descriptor.
This means that descriptor sets can have "holes" in them, with some bindings being valid and some not. But note the language in the spec, it says "dynamically used". This means that descriptor set bindings can be statically declared inside the shader, but if the shader doesn't actually access a particular item when it's run, it doesn't have to contain a valid descriptor. It is impossible to predict which items a shader will access without executing the entire shader in advance somehow, which is completely infeasible for Vulkano.
This means that Vulkano cannot rely on declarations in the shader at all when checking the validity of resources bound to descriptors. It has no idea which items will be accessed, and therefore which must be valid at draw/dispatch time. This makes it pretty much impossible to implement this safely with proper validation. The official validation layer doesn't bother validating it either; if the binding has this flag it just skips validating the resources for the entire binding.
So, how can Vulkano support this flag? It's obviously very useful, but we have to accept that it's going to be unsafe somehow. Is there a way that the API can minimise the unsafety?
The text was updated successfully, but these errors were encountered:
So, how can Vulkano support this flag? It's obviously very useful, but we have to accept that it's going to be unsafe somehow. Is there a way that the API can minimise the unsafety?
Could static analysis of the shader source be useful here?
I'm not sure if that could eliminate all unsafety. Imagine that the shader has some complicated logic to figure out the index of an array element in a binding, that uses a variety of input variables. Inputs could be from vertex buffers, uniform buffers and even images. For Vulkano to figure out what index the shader will end up accessing, and therefore which descriptor needs to be valid at draw/dispatch time, it would have to know all these inputs and execute the code that calculates the final index from them. While this isn't completely impossible, it essentially involves building an "emulator" for SPIR-V. It would be extremely impractical to attempt this in Vulkano, not only because of the complexity involved, but also because of the performance costs it would add to each draw/dispatch call.
The Vulkan spec says:
This means that descriptor sets can have "holes" in them, with some bindings being valid and some not. But note the language in the spec, it says "dynamically used". This means that descriptor set bindings can be statically declared inside the shader, but if the shader doesn't actually access a particular item when it's run, it doesn't have to contain a valid descriptor. It is impossible to predict which items a shader will access without executing the entire shader in advance somehow, which is completely infeasible for Vulkano.
This means that Vulkano cannot rely on declarations in the shader at all when checking the validity of resources bound to descriptors. It has no idea which items will be accessed, and therefore which must be valid at draw/dispatch time. This makes it pretty much impossible to implement this safely with proper validation. The official validation layer doesn't bother validating it either; if the binding has this flag it just skips validating the resources for the entire binding.
So, how can Vulkano support this flag? It's obviously very useful, but we have to accept that it's going to be
unsafe
somehow. Is there a way that the API can minimise the unsafety?The text was updated successfully, but these errors were encountered: