[PATCH] d3d12: Check for VK_KHR_external_fence_capabilities before using VkPhysicalDeviceIDProperties.
Philip Rebohle
philip.rebohle at tu-dortmund.de
Thu Feb 25 15:59:10 CST 2021
Am 25.02.21 um 17:38 schrieb Zebediah Figura (she/her):
> On 2/25/21 10:18 AM, Joshua Ashton wrote:
>> On 2/25/21 4:01 PM, Zebediah Figura (she/her) wrote:
>>> On 2/25/21 7:00 AM, Joshua Ashton wrote:
>>>> There is no reason to. This is core in Vulkan 1.1.
>>>>
>>>> You should just use a newer API version.
>>>> There is no relevant driver that doesn't support this.
>>>
>>> Mesa's v3dv is an example of a driver that does not support Vulkan 1.1.
>>
>> That is not relevant hardware:
>> It is not capable of supporting D3D12.
>
> If it's capable of supporting vkd3d, it's capable of supporting d3d12 ;-)
>
> (Granted, the former may actually not be the case, for lack of
> KHR_shader_draw_parameters. I don't know if that's possible to implement.)
>
> More to the point, though, there are more salient reasons to support
> Vulkan 1.0: drivers not yet written (e.g. there is not yet a free NVidia
> or Mali driver, nor a conformant software driver), drivers whose latest
> versions are not accessible (e.g. the last version of MoltenVK that can
> be built for MacOS Mojave only supports Vulkan 1.0), hardware which may
> not be capable of supporting Vulkan 1.1 (if any exists), and less
> painful bisection of Vulkan drivers down to old versions. Compared with
> the cost of adding a couple lines, and that only because I happened to
> run the validation layers, I'm not particularly inclined to believe
> dropping support for Vulkan 1.0 is a worthwhile trade.
If anyone ever asked me why vkd3d-proton exists as a fork, this would be
a perfect example.
The point Josh is trying to make here is that any new-ish driver project
will of course be aiming for Vulkan 1.0 conformance with a limited
feature set before adding all the optional stuff that was added later,
simply because it's easier and faster to bring up. v3dv reached this
point three months ago. It already supports a bunch of features that
were promoted to Vulkan 1.1 such as the external memory stuff, but is
still missing some others. It'll get there eventually.
Thing is, the feature set that these young implementations provide is
barely enough to support a D3D9 feature set, and that is if you emulate
basic functionality like block-compressed textures because the Vulkan
implementation doesn't even support those (v3dv can't due to hardware
limitations, Swiftshader could but doesn't, etc.). If we're *very*
generous, we're looking at a subset of D3D11 FL11_0 functionality with
loads of inefficient hacks to make things like D3D11_DSV_READ_ONLY_DEPTH
work, recompiling compute shaders with the exact view formats in mind
because shaderStorageWriteWithoutFormat isn't supported, and the list
could go on forever, there's so much that these drivers just do not
support yet in any reasonable way. And god beware if anyone actually
tries to use geometry shaders.
For D3D12 you can't even emulate all the missing stuff. The binding
model just doesn't give you enough information at the time command lists
are being recorded to work around any of this. That is, if you actually
implement it correctly and support update-after-bind semantics and
descriptor indexing, which are not optional in D3D12.
Has anyone other than Józef actually done any sort of research into how
the API works and evaluated what kind of baseline feature set is
required to drive a translation layer? The "Vkd3d known issues" page on
winehq itself provides more than enough insight on why a baseline Vulkan
1.0 implementation simply cannot run this API even remotely reasonably.
There are solutions to most of them nowadays, but a lot of the upstream
vkd3d code has been written before those were available.
I can sort of understand MoltenVK on Mojave as a somewhat valid reason
to keep an old code path around, provided that there actually some D3D12
content working on that combination in the first place, but instead of
making D3D work properly on platforms which *do* provide a good enough
Vulkan environment, now we're discussing a feature that was promoted to
the core Vulkan spec *three years ago* to cater to platforms that can't.
And then people are wondering why we don't try to work with upstream
anymore.
- Philip
>
>>
>> - Joshie 🐸✨
>>
>>>
>>>>
>>>> - Joshie 🐸✨
>>>>
>>>
>>
>
>
More information about the wine-devel
mailing list