protonscr

Question: About VK_EXT_descriptor_indexing 1M resources requirement..

vkd3dclosed
HansKristian-Work/vkd3d-proton#379 · opened 2020-11-11 by oscarbg · updated 2020-11-11 · 2 comments · github
Ooscarbg 2020-11-11 github

Hi,
just asking, because I shared current VKD3D Vulkan requirements to MoltenVK devs and they answered:

(https://github.com/KhronosGroup/MoltenVK/issues/214#issuecomment-725225237)

What I don't get is why VK_EXT_descriptor_indexing with 1M is required. It should be possible to support D3D12_RESOURCE_BINDING_TIER_1 without it. Also, we can't support 1,000,000 resources, even with argument buffers: Metal only guarantees 500k. I've asked Apple for that, too (FB8877050).

VK_KHR_buffer_device_address - I've repeatedly begged Apple for this (FB6908280), but they've balked at it so far.

VK_EXT_extended_dynamic_state - We can't implement this right now, because Metal does not yet support dynamic vertex buffer stride. All the other extended dynamic states are supported by Metal. I have asked Apple for this (FB7648364).

we read they could theoretically support up to 500k via argument buffers.. so asking if any DX12 of the games which currently run under VKD3D need as many of these resources (>500k)..
note I'm aware MoltenVK may have other current limitations (bugs) which avoid running these complex D3D12 workloads/games to run using these wrapper..
as we see they asked Apple to increase 500k currently max supported argument buffers..
altough not original question I will also be happy to hear how the two other "impracticable" to support extensions in Metal may affect potential VKD3D compatibility/performance under MoltenVK..

thanks for your time in advance.. :-)

HHansKristian-Work maintainer 2020-11-11 github

we read they could theoretically support up to 500k via argument buffers.. so asking if any DX12 of the games which currently run under VKD3D need as many of these resources (>500k)..

Most games create 1M heaps.

note I'm aware MoltenVK may have other current limitations (bugs) which avoid running these complex D3D12 workloads/games to run using these wrapper..

Metal is fundamentally incompatible with the D3D12 binding model. To create IABs on Metal you have to know the exact texture type and MSAA state, D3D12 is on the other hand extremely generic. There is no feasible way to implement this at all. It's barely implementable on Vulkan as-is.

TIER_1 is D3D11. Very few games will run correctly with just that. It's also unimplementable without descriptor_indexing UPDATE_AFTER_BIND since we need to consider RS 1.0 VOLATILE semantics. Not implementing this correctly breaks at least WoW.

Fundamentally, Metal is just incompatible with D3D12's binding model. It is not a priority for us to hack around this fact.

VK_KHR_buffer_device_address will be hard requirement for ray tracing down the line.

VK_EXT_extended_dynamic_state ensures we don't get insane shader compilation stutter.

Ooscarbg 2020-11-11 github

thanks for response.. it's valuable..

Upstream links