[PATCH] d3d12: Check for VK_KHR_external_fence_capabilities before using VkPhysicalDeviceIDProperties.
This fixes a validation layer warning.
Signed-off-by: Zebediah Figura z.figura12@gmail.com --- dlls/d3d12/d3d12_main.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/dlls/d3d12/d3d12_main.c b/dlls/d3d12/d3d12_main.c index 3dd4ec796b0..5ac10689323 100644 --- a/dlls/d3d12/d3d12_main.c +++ b/dlls/d3d12/d3d12_main.c @@ -265,7 +265,9 @@ static VkPhysicalDevice d3d12_get_vk_physical_device(struct vkd3d_instance *inst if ((vr = pfn_vkEnumeratePhysicalDevices(vk_instance, &count, vk_physical_devices)) < 0) goto done;
- if (!IsEqualGUID(&adapter_info->driver_uuid, &GUID_NULL) && pfn_vkGetPhysicalDeviceProperties2) + if (!IsEqualGUID(&adapter_info->driver_uuid, &GUID_NULL) && pfn_vkGetPhysicalDeviceProperties2 + && check_vk_instance_extension(vk_instance, pfn_vkGetInstanceProcAddr, + VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME)) { TRACE("Matching adapters by UUIDs.\n");
@@ -331,6 +333,7 @@ HRESULT WINAPI D3D12CreateDevice(IUnknown *adapter, D3D_FEATURE_LEVEL minimum_fe }; static const char * const optional_instance_extensions[] = { + VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME, VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME, }; static const char * const device_extensions[] =
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=86076
Your paranoid android.
=== debiant2 (32 bit report) ===
Report validation errors: The report seems to have been truncated
On Wed, 24 Feb 2021 at 21:59, Zebediah Figura z.figura12@gmail.com wrote:
@@ -331,6 +333,7 @@ HRESULT WINAPI D3D12CreateDevice(IUnknown *adapter, D3D_FEATURE_LEVEL minimum_fe }; static const char * const optional_instance_extensions[] = {
VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME, VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME,
I suppose this is fine, although as a principle I would prefer using the slightly older VK_KHR_external_memory_capabilities extension for this.
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.
- Joshie 🐸✨
On 2/25/21 12:05 PM, Henri Verbeet wrote:
On Wed, 24 Feb 2021 at 21:59, Zebediah Figura z.figura12@gmail.com wrote:
@@ -331,6 +333,7 @@ HRESULT WINAPI D3D12CreateDevice(IUnknown *adapter, D3D_FEATURE_LEVEL minimum_fe }; static const char * const optional_instance_extensions[] = {
VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME, VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME, };I suppose this is fine, although as a principle I would prefer using the slightly older VK_KHR_external_memory_capabilities extension for this.
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.
- Joshie 🐸✨
- Joshie 🐸✨
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.
- Joshie 🐸✨
- Joshie 🐸✨
February 25, 2021 10:39 AM, "Zebediah Figura (she/her)" zfigura@codeweavers.com wrote:
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),
s/for/on
You should be able to *use* the resulting binary on Mojave.
Chip
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 🐸✨
On 2/25/21 3:59 PM, Philip Rebohle wrote:
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.
Cards on the table, then: I really don't know what I'm talking about.
I look at this code and say, "I don't know the consequences of making that extension, or Vulkan 1.1, mandatory, but checking for the extension's presence looks like a right solution and is easy." vkd3d-proton exists as a fork because, for better or for worse, there are those of us who are not willing to settle for that.
My mistake here is trying to defend my choice on what I think are the appropriate devil's-advocate grounds. Trouble is: I really don't know what I'm talking about. I certainly haven't done that research you're asking about. But as far as I see, vkd3d-proton also exists because both sides got fed up with the other not responding to their concerns and decided to stop interacting. Given the choice I'll make the mistake of trying to fix that, at the risk of making some pretty bad arguments. [Because someone has to, and no one else will.]
The concern of changes like requiring 1.1 (and, more importantly, dropping all the 1.0-specific code and feature checks) making it harder to bisect was the only one that was actually raised to me as a salient point; the others were my own points and should probably be ignored. If nothing else, maybe we can argue about that part?
- Philip
- Joshie 🐸✨
- Joshie 🐸✨
Am 25.02.21 um 23:17 schrieb Zebediah Figura (she/her):
On 2/25/21 3:59 PM, Philip Rebohle wrote:
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.
Cards on the table, then: I really don't know what I'm talking about.
I look at this code and say, "I don't know the consequences of making that extension, or Vulkan 1.1, mandatory, but checking for the extension's presence looks like a right solution and is easy." vkd3d-proton exists as a fork because, for better or for worse, there are those of us who are not willing to settle for that.
My mistake here is trying to defend my choice on what I think are the appropriate devil's-advocate grounds. Trouble is: I really don't know what I'm talking about. I certainly haven't done that research you're asking about. But as far as I see, vkd3d-proton also exists because both sides got fed up with the other not responding to their concerns and decided to stop interacting. Given the choice I'll make the mistake of trying to fix that, at the risk of making some pretty bad arguments. [Because someone has to, and no one else will.]
The concern of changes like requiring 1.1 (and, more importantly, dropping all the 1.0-specific code and feature checks) making it harder to bisect was the only one that was actually raised to me as a salient point; the others were my own points and should probably be ignored. If nothing else, maybe we can argue about that part?
Harder to bisect what though? I guess for MVK you do have a point there since Vulkan 1.1 support is still somewhat recent there, but the value of this will deminish as time passes (also, there's a boatload of other issues with trying to run D3D12 on Metal, but that's being discussed on the MVK issue tracker so I'm not going to go into detail on that front; safe to say that Metal itself is unfortunately not a very good API for layering purposes).
For Mesa it's already not really useful to bisect very old issues in my experience; ancient Mesa versions are hard to build due to the LLVM build-time requirement as well and the drivers have seen significant changes since then as well (new compiler, tons of issues being caused by LLVM itself, etc). Unless a regression has happened within the last two or so major releases, it's probably more productive to just post a RenderDoc capture or small test case to reproduce an issue with and move on.
Now arguably your patch doesn't really do anything that would mandate switching to 1.1; what really blew my fuse here is that in order to work around a validation layer bug you were asked to check for a ubiquitous extension from over four years ago instead of an equally ubiquitous extension from over three and a half years ago which also happens to be the one that validation is actually complaining about.
One might ask if it's worth working around a validation bug that's likely to get fixed properly at some point in the first place, but in all fairness, there's arguments to be made for it especially if it has consequences other than some annoying log spew.
FWIW, 1.1 turned out to be necessary to support Shader Model 6 (which is actively being used in newer D3D12 content, and was actually the last thing we *tried* to upstream with Hans-Kristian's dxil-spirv library, go figure), subgroup operations in particular, since there's no equivalent extension you can just enable on a 1.0 device, which left all the 1.0 fallback code there to rot and be a maintenance burden. Vulkan is still an evolving ecosystem and D3D12 is a moving target with new things being tacked on in every major Windows release, compromises for driver/hardware support will have to be made at some point as newer features get adopted.
- Philip
- Philip
- Joshie 🐸✨
- Joshie 🐸✨
On 2/25/21 5:33 PM, Philip Rebohle wrote:
Am 25.02.21 um 23:17 schrieb Zebediah Figura (she/her):
On 2/25/21 3:59 PM, Philip Rebohle wrote:
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.
Cards on the table, then: I really don't know what I'm talking about.
I look at this code and say, "I don't know the consequences of making that extension, or Vulkan 1.1, mandatory, but checking for the extension's presence looks like a right solution and is easy." vkd3d-proton exists as a fork because, for better or for worse, there are those of us who are not willing to settle for that.
My mistake here is trying to defend my choice on what I think are the appropriate devil's-advocate grounds. Trouble is: I really don't know what I'm talking about. I certainly haven't done that research you're asking about. But as far as I see, vkd3d-proton also exists because both sides got fed up with the other not responding to their concerns and decided to stop interacting. Given the choice I'll make the mistake of trying to fix that, at the risk of making some pretty bad arguments. [Because someone has to, and no one else will.]
The concern of changes like requiring 1.1 (and, more importantly, dropping all the 1.0-specific code and feature checks) making it harder to bisect was the only one that was actually raised to me as a salient point; the others were my own points and should probably be ignored. If nothing else, maybe we can argue about that part?
Harder to bisect what though? I guess for MVK you do have a point there since Vulkan 1.1 support is still somewhat recent there, but the value of this will deminish as time passes (also, there's a boatload of other issues with trying to run D3D12 on Metal, but that's being discussed on the MVK issue tracker so I'm not going to go into detail on that front; safe to say that Metal itself is unfortunately not a very good API for layering purposes).
For Mesa it's already not really useful to bisect very old issues in my experience; ancient Mesa versions are hard to build due to the LLVM build-time requirement as well and the drivers have seen significant changes since then as well (new compiler, tons of issues being caused by LLVM itself, etc). Unless a regression has happened within the last two or so major releases, it's probably more productive to just post a RenderDoc capture or small test case to reproduce an issue with and move on.
I don't think I can offer any meaningful comment here. I do get the impression that most of the vkd3d contributors (current and past?) have preferred debugging strategies that don't rely on renderdoc/apitrace/etc., but I really can't evaluate the relative merits. I don't necessarily think it's right to say "it's not worth supporting bisects even if you prefer them", though.
Now arguably your patch doesn't really do anything that would mandate switching to 1.1; what really blew my fuse here is that in order to work around a validation layer bug you were asked to check for a ubiquitous extension from over four years ago instead of an equally ubiquitous extension from over three and a half years ago which also happens to be the one that validation is actually complaining about.
One might ask if it's worth working around a validation bug that's likely to get fixed properly at some point in the first place, but in all fairness, there's arguments to be made for it especially if it has consequences other than some annoying log spew.
I'm not sure it's reasonable to object to that. I think the general policy of "don't drop support for anything without a strong reason", for some definition of "strong", is worth reëvaluating, in this case if nothing else. But under the bounds of that policy, I think Henri's review is right (and the validation layers *are* broken—and I don't think we really care about fixing the warnings per se as much as fixing the correctness issues they find. Which, for an API like Vulkan... I'd be perfectly willing to believe that the driver takes a missing extension like this as license to randomly crash 5 minutes later into the program.)
FWIW, 1.1 turned out to be necessary to support Shader Model 6 (which is actively being used in newer D3D12 content, and was actually the last thing we *tried* to upstream with Hans-Kristian's dxil-spirv library, go figure), subgroup operations in particular, since there's no equivalent extension you can just enable on a 1.0 device, which left all the 1.0 fallback code there to rot and be a maintenance burden. Vulkan is still an evolving ecosystem and D3D12 is a moving target with new things being tacked on in every major Windows release, compromises for driver/hardware support will have to be made at some point as newer features get adopted.
In case it was unclear, I think (or at least assume) the intent for vkd3d is to conditionally request newer versions depending on the requested feature level, and then leave 1.0-compatible paths (or whatever) for any lower feature level, whereas the SM6 translation would only be allowed if the relevant feature level is enabled. That's roughly the way wined3d's GL backend works, minus the part where extensions and versions have to be explicitly enabled.
I suspect that vkd3d-proton (and maybe even DXVK) operates in general on lines of thought like "we are sure that the AMD and NVidia GPUs/drivers all support this (or soon will), and we don't care about any others, therefore we will require it even if the game doesn't ask for it", possibly paired with "we are sure that no game will not ask for it". Possibly this is paired with a policy to implement fallback paths if those assertions turn out to be wrong, or possibly just "it's not worth supporting this for your GPU, get a better one" (I certainly hope the latter isn't the case, but from interacting with the DXVK community I get a strong impression that it is. But it's not obvious to me that the former is actually a bad idea. Or maybe it really depends on Vulkan being so new.)
I similarly suspect that wined3d is operating on years of users complaining when things get broken, and has therefore adopted a defensive position of "just don't drop support for things; instead restructure to allow newer features to give you fast paths". I mean, I know this is true for the broader wine project—it probably strikes those in the DXVK community as bizarre how much we care about regressions. But I can see disadvantages: this does create a maintenance burden, one way or another, and it of course risks being pointlessly defensive.
It would be really nice if we can find a middle ground. I'm not trying to evangelize compromise here qua compromise—there are a couple high-level things about wine's development process I like a *lot* better than DXVK/vkd3d-proton, and in some cases even think are objectively better. Like, even if I didn't have a severe emotional investment in the feud [not that I'm sure which way that biases me—believe me when I say that both sides carry significant blame], and even if I could contribute to DXVK without possible licensing problems, I know which project I would prefer contributing to.
But in a case like this—and I mean the general disagreement of whether to aggressively keep legacy code around or aggressively require the latest drivers/GPU, I can see the arguments for both sides, or some middle ground. And I find it tragic that the expertise and experience that all of the people here who aren't me have is just not respected, and that everyone's reaction to disagreement is to immediately disengage. I find it especially tragic because I'm not sure that under Henri couldn't be convinced to just require Vulkan 1.1—but nobody's really tried. If I'm trying to do anything here it's to get these issues out in the open and discussed.
- Philip
- Philip
- Joshie 🐸✨
> > - Joshie 🐸✨ >
-
Chip Davis -
Henri Verbeet -
Joshua Ashton -
Marvin -
Philip Rebohle -
Zebediah Figura -
Zebediah Figura (she/her)