-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for a generic descriptor indexing intrinsic #4351
Comments
We should provide something similar to Since D3D12/HLSL use separate descriptor heap for resources and samplers, we likely will need to keep them separate in Slang so we have a way to map to HLSL. We would be happy to take patches for this implementation. The interface you proposed is fine, my only comment is that we should separate |
We need to figure out how this DescirptorArray is reported by reflection API, and how to assign bindings for it. In our layout rules, we should make it so that a DescriptorArray occupies a whole space, and is reflected as an unsized array of |
Thanks for your comments. I agree about separating the resource and sampler heaps, but I'm a bit confused about whether these should be implemented with two different types or with the proposed type but in different globals for the (future) HLSL target. A constrained generic type in the struct could also work, although there doesn't seem to be a common interface for buffers yet. The layout rules and reflection types make sense, I had not thought much of them at first so that is nice info to have :) |
I will be happy to be wrong but it may fall in to a known limitation described in #3804. |
The red underline there means the type system is working as intended. A |
Can the "Resource" and "Sampler" integers there be integers evaluated at runtime? Eg,
|
Isn't the motivation for such a feature exactly this though? It should be possible to dynamically have different types bound to different offsets within the same descriptor array.
|
We can have different type of Resources in the ResourceArray, but you can't get a Resource handle from a Sampler array. This is because HLSL/D3D distinguishes a Sampler descriptor heap from a resource descriptor heap, unlike in Vulkan everything can be placed in a single descriptor set allocated from a single descriptor heap. |
You mean the index passsed to |
For some context, this is what I'm kinda forced into doing at the moment with Slang. I force users to include some code which inlines the below descriptor arrays, which then I can sorta manage myself in the host code.
But this is also very constraining. For example, I can't distinguish between different buffer types. At the same time, I can't just enumerate all the different types of descriptors and make bindings for each one. |
It's also very frustrating to need to include texture1Ds and texture3Ds when more often than not, folks using my framework don't use them. I have to add in these placeholder descriptors for each new type, eg a volume of 1 voxel, texture with 1 pixel, a buffer with one integer. It would be really nice if I didn't have to do that... |
I see. I'm coming from a Vulkan user's perspective. I'm probably ok to just separate out the samplers into their own dedicated array. Just so long as the N other resource types could all be put together. |
@dubiousconst282 Can you let us know if this is something you'll be working on in the near term? Thank you! |
Yes, I am working on a draft and will be ready to submit a PR shortly (hopefully before the end of the week). |
It appears that I misunderstood what was asked. Thanks for the link at the very beginning. |
Descriptor indexing allows shaders to access resources in a natural and flexible way, while further eliminating the complexity of managing and updating descriptor sets. This feature can already be used today in Slang, but it requires that global bindings be declared for every accessed resource type and format beforehand, which can become a bit tedious and makes it difficult for users to implement abstractions on top.
Following from #4150, it is not possible to define bindings inside a generic type due to design constraints in the compiler. What I propose instead, is for Slang to provide an intrinsic type that allows indexing over arbitrary resource types, similarly to
ResourceDescriptorHeap
in HLSL. This way, only one binding variable would need to be defined per descriptor set and binding index:The SPIRV backend would then emit the appropriate
OpVariable
definitions as it finds the specialized Get() calls. Potentially, this could also be used to implement the HLSL global heaps in a relatively portable way, although I'm not familiar with their binding model.If this gets approved, I would be willing to work on an implementation if that is preferred.
The text was updated successfully, but these errors were encountered: