dx12: Descriptor Pool limitations

[msiglreith]

Descriptor pools map 1:1 to a slice in the global descriptor heap (1M descriptors, 2k samplers).
Overallocation would be troublesome, but Vulkan allows to have more. Even some CTS tests relay on it as well as some real world applications.
Emulating this is quite costly and I would love to avoid this. At the end this depends on what Khronos Working Group decides on.

[kvark]

FTR, Khronos TSG didn't decide to change these in any way since we said that it's possible on D3D12. I thought we had a rough plan on supporting multiple pools in play, and it's more a matter of implementation complexity than resulting performance.

[msiglreith]

well, yes, it's doable but requires a lot of descriptor juggling. Performance impact is hard to estimate I would say. At the end, exposing a feature to restrict stuff might give the user the best of both worlds?

[kvark]

Do you have an idea of how this could sound in the spec? Saying something straightforward like "at no point should a draw call use bindings from multiple descriptor pools, unless there is one for samplers specifically" :)

[msiglreith]

Exposing an upper limit of concurrently allocated descriptors types by descriptor pools coupled with error on descriptor pool allocating due to fragmentation etc.
This would allow to hide the heap as implementation detail. Maybe in far future Vulkan 3 will move towards Mantle definition of descriptor sets :P

[kvark]

Interestingly, the number of samplers is already capped in Vulkan: maxSamplerAllocationCount

[msiglreith]

right, nonetheless, ordered array of samplers as found in descriptor sets are more of an issue. Even though we can create 2k samplers easily (still less than 4k guarenteed by vulkan) and would be able to store them in gpu heaps we still need to deal with the issue of the user being able to arbitrarily combine them.

[kvark]

Sampler limitations are addressed in #3393