Supporting push descriptors would be rather difficult for us, and only work under specific circumstances.

• Push descriptors straight-up would not work in combination with pipeline libraries, since we cannot know the full descriptor layout at the time fragment shader pipelines or pre-rasterization pipelines are compiled. We'd need to implement a completely new code path for descriptor mapping etc. that would only be used with monolithic pipelines and push descriptors.
• maxPushDescriptors is 32 on most drivers, which is far from enough for many modern D3D11 games, which often use anything from 50-70 resources per draw in their main render pass.

Furthermore, if the goal is to only update dirty descriptors, there are more issues which are hard to resolve and would substantially increase CPU overhead on native implementations:

• The Vulkan descriptor layout depends on the currently active shaders, but we simply cannot know this information until draw time. So, resolving dirty descriptors would still have to happen at draw time anyway.
• The descriptor type also depends on the currently bound shaders, since D3D allows things like binding a 2D array view when the shader expects plain 2D, or binding a texel buffer view when the shader expects a raw buffer.
• Currently bound buffers can have their backing storage changed (via MAP_WRITE_DISCARD and friends), so we'd need to track which slots a buffer and any of its views are bound to. The current solution is to just update the buffer descriptor sets in their entirety.

If Zink somehow manages to deal with all of this efficiently, there's some serious amount of magic going on, but given that supporting this would require yet another large-scale rework and would most certainly come at a cost for non-virtualized environments, I can't say I'm particularly interested in supporting that upstream, especially since our current implementation is fine for native hardware drivers.

For the record, we already use plain vkUpdateDescriptorSets rather than templated updates on 64-bit builds, and we also don't use things like UPDATE_AFTER_BIND.

Looks like Zink only uses push descriptors for the GL uniform descriptor set.
Everything else (UBOs, SSBOs, storage images, sampled images) goes through the regular uniform set update path.
Zink also only seems to only create pipelines that contain all shader stages.

Caching descriptor sets is also highly impractical. We can't predict resource lifetimes, we'd additionally have to manage lifetimes of individual descriptor sets, we'd have to deal with descriptor pool fragmentation in some way to not use too much memory, and the key to look up sets would be an arbitrarily sized array of (resource cookie, vk view handle / buffer offset) tuples (i.e. 16 bytes per descriptor) since apps have total freedom on what to bind when and where.

Also, if Zink's past experience with descriptor set caching is anything to go by, it's straight-up going to be much slower than simply updating descriptor sets on native drivers as well, so we'd need to keep the current code around.

One thing I tried in the past was to just use UPDATE_AFTER_BIND and defer descriptor set updates to our command submission thread, so that we'd only have one single call to vkUpdateDescriptorSets per command list and have it run on a much less busy thread. Would that be helpful at all here? This was also significantly slower on native drivers that the current path so I dropped the idea, but it's certainly easier to maintain alongside the current path than any of the proposed alternatives.

In the end though, making descriptor set updates a slow path is always going to hurt DXVK in one way or another, and probably many other Vulkan applications (certain games, emulators, vkd3d-proton) as well. We're going to have this problem with Wine in the future as well, and it's really annoying, but really doesn't look like there's any way at all to maintain the level of performance that we currently have when high-frequency operations like that have significant overhead.

Regarding EXT_descriptor_buffer, I have no immediate plans to integrate this into DXVK either. It would solve some annoyances we currently have with descriptor set allocation (vkAllocateDescriptorSets is already so expensive that we need to avoid it).

However it introduces vkGetDescriptorEXT, and it goes without saying that DXVK cannot pay the full syscall penalty for every descriptor in the worst case. Caching would work for image and sampler descriptors, but not for (most) buffer descriptors since buffer addresses will change arbitrarily between draws. It also negatively affects GPU performance on some vendors.

I feel like a potential long-term solution would involve something like EXT_descriptor_buffer for image descriptors, as well as for buffer descriptors in pipelines created from pipeline libraries. For optimized pipelines we'd have to put buffer descriptors into push descriptors to avoid the downsides of descriptor buffers. However, this would be another major rewrite of our descriptor model (would take months, the rewrite I had to do for GPL already took a while but this would be much, much more complex) and we'd still have to keep a legacy descriptor set path for drivers that don't support the required features, so I'm not sure how feasible this is at all.