vkd3d: Allow overriding the device capabilities.
This goes atop !981 (merged) and indirectly obsoletes !973 (closed).
Since we were overestimating them, this patch will likely result into reducing the reported resource binding tier in many configurations, which could in turn make some game refuse to run. I have no numbers here, but we might consider introducing an environment variable to fake the reported tier (in principle also for other variables, like the feature level). Might that be a good idea?
Merge request reports
Activity
I didn't check whether the limits match the documented/reported limits, but conceptually this makes sense to me. It may already be a bit late in the release process for this kind of change though, considering the potential to regress things.
Since we were overestimating them, this patch will likely result into reducing the reported resource binding tier in many configurations, which could in turn make some game refuse to run. I have no numbers here, but we might consider introducing an environment variable to fake the reported tier (in principle also for other variables, like the feature level). Might that be a good idea?
I think so. Ideally we'd do that in a way that avoids ending up with a million ad-hoc configuration knobs though.
I didn't check whether the limits match the documented/reported limits, but conceptually this makes sense to me. It may already be a bit late in the release process for this kind of change though, considering the potential to regress things.
For the context, the limits I compared with are https://learn.microsoft.com/en-us/windows/win32/direct3d12/hardware-support. Unfortunately we need two Vulkan descriptors for each D3D12 SRV descriptor (a sampled image descriptor and a uniform texel buffer descriptor) and three Vulkan descriptors for each D3D12 UAV descriptor (a storage image descriptor, a storage texel buffer descriptor and another storage texel buffer descriptor for the counter). This, combined with the fact that many Vulkan implementations support at most 10^6 or 2^10 bound descriptors means that for most Vulkan implementations we're bound to report only tier 1, so I agree that's for after the release.
Also, technically the Microsoft limits are only for root signature descriptor tables, while in the Vulkan set layouts we also have to squeeze the static samplers, root descriptor parameters and possibly another uniform buffer the day we implement push constant spilling. I'll revise the MR requesting slightly larger limits.
I think so. Ideally we'd do that in a way that avoids ending up with a million ad-hoc configuration knobs though.
Something like
VKD3D_CONFIG=force_resource_binding_tier_3,force_feature_level_12_1
.
I think so. Ideally we'd do that in a way that avoids ending up with a million ad-hoc configuration knobs though.
Something like
VKD3D_CONFIG=force_resource_binding_tier_3,force_feature_level_12_1
.Yeah, that's what I'd like to avoid. :) (Because then you'd need a "force_feature_level_12_0" to force 12.0, a "force_feature_level_12_2" to force 12.2, and so on, not to mention all the other caps bits.)
Yeah, that's what I'd like to avoid. :) (Because then you'd need a "force_feature_level_12_0" to force 12.0, a "force_feature_level_12_2" to force 12.2, and so on, not to mention all the other caps bits.)
What would be better?
VKD3D_CONFIG=force_resource_binding_tier=3,force_feature_level=12.1
? Or directlyVKD3D_CONFIG=force_max_capabilities
to just pretend we can do everything? This latter feels a bit excessive. BTW, I didn't plan to add any possible capability, just those that make sense. Anyway, whatever you consider appropriate.
What would be better?
VKD3D_CONFIG=force_resource_binding_tier=3,force_feature_level=12.1
? Or directlyVKD3D_CONFIG=force_max_capabilities
to just pretend we can do everything? This latter feels a bit excessive. BTW, I didn't plan to add any possible capability, just those that make sense. Anyway, whatever you consider appropriate.The truth is I don't necessarily know the right answer. I was thinking about something like VKD3D_CONFIG=caps_override=feature_level=12.1:resource_binding_tier=3, or perhaps VKD3D_CAPS_OVERRIDE=feature_level=12.1,resource_binding_tier=3.
added 40 commits
-
95212d3c...b23874da - 38 commits from branch
wine:master
- e4b07a10 - vkd3d: Compute the resource binding tier taking all resources into account.
- a2b45eeb - vkd3d: Check root signature validity before checking whether we support it.
-
95212d3c...b23874da - 38 commits from branch
I ended up writing an even stronger resource binding tier checker, which accounts for the fact that some of the native limits are expressed per stage. That means that in theory a pipeline can have five different stages, each of which is using its own set of 1M descriptors. Since every D3D12 SRV descriptor requires 2 Vulkan descriptors, that could amount to a total of 10M Vulkan descriptors, which not many GPUs declare to support. That's clearly an extreme case, but in theory we're supposed to support it if we want to declare tier 2 or more (unless I'm reading the Microsoft docs wrong).
So in principle I think my code is correct; in practice we might want to do something more relaxed, but then I'm not sure of where to draw the line.
I ended up writing an even stronger resource binding tier checker, which accounts for the fact that some of the native limits are expressed per stage. That means that in theory a pipeline can have five different stages, each of which is using its own set of 1M descriptors.
Yes, but it doesn't mean you can e.g. store 5M SRV descriptors in a single descriptor heap on tier 2 and then bind that single heap to 5 stages; you'd have to use 5 heaps with 1M descriptors each. In principle you can do that in Vulkan as well if you have maxPerStageDescriptorSampledImages >= 1M, maxDescriptorSetSampledImages >= 1M, and maxBoundDescriptorSets >= 5.
What makes it complicated is the mapping between the two we do in vkd3d, and the available extensions and descriptor heap implementation used have some influence on what the exact answer from compute_resource_binding_tier() is supposed to be. I don't think we should need the multiplication by max_pipeline_stages in any of those cases though?
Yes, but it doesn't mean you can e.g. store 5M SRV descriptors in a single descriptor heap on tier 2 and then bind that single heap to 5 stages; you'd have to use 5 heaps with 1M descriptors each. In principle you can do that in Vulkan as well if you have maxPerStageDescriptorSampledImages >= 1M, maxDescriptorSetSampledImages >= 1M, and maxBoundDescriptorSets >= 5.
You're right. Indeed, it's even stronger than that, it seems: assuming that a CBV-SRV-UAV descriptor heap can hold at most 1M descriptors, and since you can bind at most CBV-SRV-UAV descriptor heap per pipeline (not per stage), you just can't bind more than 1M resource view descriptors. There might be some more complexity, as you say, but my multiplying by the stage count is indeed way excessive.
added 70 commits
-
a27f7243...6d28cc13 - 67 commits from branch
wine:master
- 0b32e5c4 - vkd3d: Compute the resource binding tier taking all resources into account.
- faaf9ef2 - vkd3d: Check root signature validity before checking whether we support it.
- f9d4f52d - vkd3d: Allow overriding the device capabilities.
Toggle commit list-
a27f7243...6d28cc13 - 67 commits from branch
added 493 commits
-
f9d4f52d...03ad04c8 - 490 commits from branch
wine:master
- 1f0bc915 - vkd3d: Compute the resource binding tier taking all resources into account.
- 98a1d40e - vkd3d: Check root signature validity before checking whether we support it.
- 9e582c32 - vkd3d: Allow overriding the device capabilities.
Toggle commit list-
f9d4f52d...03ad04c8 - 490 commits from branch
added 1 commit
- 6de3905c - vkd3d: Allow overriding the device capabilities.
added 1 commit
- a3b8aaf6 - vkd3d: Allow overriding the device capabilities.
mentioned in merge request !1275 (merged)