Skip to content
Snippets Groups Projects

vkd3d: Allow overriding the device capabilities.

Merged Giovanni Mascellani requested to merge giomasce/vkd3d:aso into master

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

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
    • 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.

    • Please register or sign in to reply
    • 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 directly VKD3D_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.

    • Please register or sign in to reply
  • What would be better? VKD3D_CONFIG=force_resource_binding_tier=3,force_feature_level=12.1? Or directly VKD3D_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.

    Compare with previous version

  • added 3 commits

    • 3cf07a82 - vkd3d: Compute the resource binding tier taking all resources into account.
    • 37affbe9 - vkd3d: Check root signature validity before checking whether we support it.
    • 91ed17ed - vkd3d: Allow overriding the device capabilities.

    Compare with previous version

  • added 3 commits

    • 1b3c0dbe - vkd3d: Compute the resource binding tier taking all resources into account.
    • 8a227d18 - vkd3d: Check root signature validity before checking whether we support it.
    • a27f7243 - vkd3d: Allow overriding the device capabilities.

    Compare with previous version

  • 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.

    • Mmh, actually this still require some more work. I'll keep it draft for the moment.

    • Please register or sign in to reply
  • 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.

    Compare with previous version

  • 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.

    Compare with previous version

  • added 1 commit

    • 6de3905c - vkd3d: Allow overriding the device capabilities.

    Compare with previous version

  • Giovanni Mascellani marked this merge request as ready

    marked this merge request as ready

  • Giovanni Mascellani changed title from Draft: vkd3d: Compute the resource binding tier taking all resources into account. to vkd3d: Allow overriding the device capabilities.

    changed title from Draft: vkd3d: Compute the resource binding tier taking all resources into account. to vkd3d: Allow overriding the device capabilities.

  • As I wrote, this is going to need some more work, but I maybe the patch to override the device capabilities is already good enough.

  • Giovanni Mascellani approved this merge request

    approved this merge request

  • I'll take it. Probably wouldn't hurt to move parsing the capability name and parsing the capability value both into their own helper function though.

  • Henri Verbeet approved this merge request

    approved this merge request

  • Henri Verbeet added 1 commit

    added 1 commit

    • a3b8aaf6 - vkd3d: Allow overriding the device capabilities.

    Compare with previous version

  • Giovanni Mascellani mentioned in merge request !1275 (merged)

    mentioned in merge request !1275 (merged)

Please register or sign in to reply
Loading