Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

How could Vulkano safely support PARTIALLY_BOUND descriptor bindings? #1743

Open
Rua opened this issue Nov 2, 2021 · 3 comments
Open

How could Vulkano safely support PARTIALLY_BOUND descriptor bindings? #1743

Rua opened this issue Nov 2, 2021 · 3 comments

Comments

@Rua
Copy link
Contributor

Rua commented Nov 2, 2021

The Vulkan spec says:

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?

@DemiMarie
Copy link

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?

@Rua
Copy link
Contributor Author

Rua commented Nov 8, 2021

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.

@DemiMarie
Copy link

Is there a reason to support this?

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

2 participants