[PATCH v2 0/2] MR11002: win32u: Enable VK_KHR_external_fence_capabilities in d3dkmt_init_vulkan().

[Francisco Casas (＠fcasas)]

According to vulkan validation layers, this instance extension is required so that vkGetPhysicalDeviceProperties2()
fills the VkPhysicalDeviceIDProperties struct.

This extension is only needed for VK_API_VERSION_1_0, since it is part of the core functionalities in VK_API_VERSION_1_1,
but win32u uses VK_API_VERSION_1_0.

Additionally, this extension is also enabled when available for wined3d when the VK_API_VERSION_1_1 is not available.

--
  v2: wined3d: Enable VK_KHR_external_fence_capabilities when initializing vulkan.
      win32u: Enable VK_KHR_external_fence_capabilities in d3dkmt_init_vulkan().
 
https://gitlab.winehq.org/wine/wine/-/merge_requests/11002

[PATCH v2 1/2] win32u: Enable VK_KHR_external_fence_capabilities in d3dkmt_init_vulkan().

[Francisco Casas]

From: Francisco Casas <[e-mail]>

The win32u dll provides NtGdiDdDDIOpenAdapterFromLUID(), which
internally uses get_vulkan_physical_device(), which initializes
the VkPhysicalDeviceIDProperties struct.

This struct is provided by the following extensions:
VK_KHR_external_fence_capabilities, VK_KHR_external_memory_capabilities,
VK_KHR_external_semaphore_capabilities.

However with VK_KHR_external_memory_capabilities we get the following
validation error, which is presumably a bug in the validation layer:

    VUID-VkPhysicalDeviceProperties2-pNext-pNext(ERROR
    / SPEC): msgNum: -579609649 - Validation Error: [
    VUID-VkPhysicalDeviceProperties2-pNext-pNext ] Object 0:
    handle = 0x5555673b5820, type = VK_OBJECT_TYPE_INSTANCE; |
    MessageID = 0xdd73dbcf | vkGetPhysicalDeviceProperties2KHR():
    pProperties->pNext includes a pointer to a VkStructureType
    (VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES), but
    its parent extension VK_KHR_external_fence_capabilities
    has not been enabled. The Vulkan spec states: Each pNext
    member of any structure (including this one) in the pNext
    chain must be either NULL or a pointer to a valid instance
    of VkPhysicalDeviceAccelerationStructurePropertiesKHR,
    [...] , or VkPhysicalDeviceVulkan13Properties
    (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/v
    kspec.html#VUID-VkPhysicalDeviceProperties2-pNext-pNext)

For this reason we replace VK_KHR_external_memory_capabilities with
VK_KHR_external_fence_capabilities.
---
 dlls/win32u/d3dkmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dlls/win32u/d3dkmt.c b/dlls/win32u/d3dkmt.c
index 38624583f7d..1b33976f333 100644
--- a/dlls/win32u/d3dkmt.c
+++ b/dlls/win32u/d3dkmt.c
@@ -491,7 +491,7 @@ static void d3dkmt_init_vulkan(void)
     static const struct vulkan_instance_extensions extensions =
     {
         .has_VK_KHR_get_physical_device_properties2 = 1,
-        .has_VK_KHR_external_memory_capabilities = 1,
+        .has_VK_KHR_external_fence_capabilities = 1,
     };
 
     d3dkmt_vulkan_instance = vulkan_instance_create( &extensions );
-- 
GitLab


https://gitlab.winehq.org/wine/wine/-/merge_requests/11002

[PATCH v2 2/2] wined3d: Enable VK_KHR_external_fence_capabilities when initializing vulkan.

[Francisco Casas]

From: Francisco Casas <[e-mail]>

Currently, the vulkan validation layers emit an error for using
VkPhysicalDeviceIDProperties when using VK_API_VERSION_1_0 without
importing any of the instance extensions that implement it, which are
VK_KHR_external_fence_capabilities, VK_KHR_external_memory_capabilities,
and VK_KHR_external_semaphore_capabilities.

VK_KHR_external_memory_capabilities (instance extension) should not be
confused with VK_KHR_external_memory (device extension), this is a
mistake in the current code.

Regardless of this, replacing with VK_KHR_external_memory_capabilities
doesn't fix the error since it seems that there is a bug in the vulkan
validation layer as well, so VK_KHR_external_fence_capabilities is
initialized instead.

This is only needed for VK_API_VERSION_1_0, since it the missing struct
is part of the core functionalities in VK_API_VERSION_1_1.

Fixes: 035dc483881225fb8181f5e4ad85d05ba5c3b989
---
 dlls/wined3d/adapter_vk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dlls/wined3d/adapter_vk.c b/dlls/wined3d/adapter_vk.c
index 55c7b167156..79014b4c331 100644
--- a/dlls/wined3d/adapter_vk.c
+++ b/dlls/wined3d/adapter_vk.c
@@ -1933,7 +1933,7 @@ static const struct
 vulkan_instance_extensions[] =
 {
     {VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME, VK_API_VERSION_1_1, FALSE},
-    {VK_KHR_EXTERNAL_MEMORY_EXTENSION_NAME,                  VK_API_VERSION_1_1, FALSE},
+    {VK_KHR_EXTERNAL_FENCE_CAPABILITIES_EXTENSION_NAME,      VK_API_VERSION_1_1, FALSE},
     {VK_KHR_SURFACE_EXTENSION_NAME,                          ~0u,                TRUE},
     {VK_KHR_WIN32_SURFACE_EXTENSION_NAME,                    ~0u,                TRUE},
 };
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/11002

[Francisco Casas (＠fcasas)]

> What matters is the spec though, and I think it disagrees with the validation layers here; VK_KHR_external_fence_capabilities, VK_KHR_external_memory_capabilities, and VK_KHR_external_semaphore_capabilities all add VkPhysicalDeviceIDProperties/VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES.
>
> In the case of wined3d, VK_KHR_external_memory_capabilities was added specifically for  VkPhysicalDeviceIDProperties in commit 035dc483881225fb8181f5e4ad85d05ba5c3b989.

I see. This made me realize though that wined3d is currently wrong since the array contains VK_KHR_external_memory (device extension) instead of VK_KHR_external_memory_capabilities (instance extension). Regardless of this, it seems that there is indeed a bug in the validation layer, perhaps they got the same confusion (?).

I replaced VK_KHR_external_memory with VK_KHR_external_fence_capabilities then.
> I suspect the win32u usage of the same extension similarly originates from commit dd25789fb24e257baea4b257deddad44d5b6fedd, but I didn't verify that.

I traced it back to 4a98b07c4bcc35a698448261478ba856c149cbea as it went through several moves. VkPhysicalDeviceIDProperties is also used there so that might be the rationale behind its inclusion. I replaced it with VK_KHR_external_fence_capabilities and the validation problem goes away, but I can't say I am sure that VK_KHR_external_memory_capabilities isn't used somewhere else by win32u since then, it might be safer to keep both extensions.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/11002#note_141768

[Henri Verbeet (＠hverbeet)]

> I see. This made me realize though that wined3d is currently wrong since the array contains VK_KHR_external_memory (device extension) instead of VK_KHR_external_memory_capabilities (instance extension).

Oh, indeed.
> Regardless of this, it seems that there is indeed a bug in the validation layer, perhaps they got the same confusion (?).

Well, if the validation layers had the same issue we wouldn't be getting the error.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/11002#note_141980

[PATCH v2 0/2] MR11002: win32u: Enable VK_KHR_external_fence_capabilities in d3dkmt_init_vulkan(). - approved

[Henri Verbeet (＠hverbeet)]

This merge request was approved by Henri Verbeet.
-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/11002

[PATCH v2 0/2] MR11002: win32u: Enable VK_KHR_external_fence_capabilities in d3dkmt_init_vulkan(). - approved

[Rémi Bernon (＠rbernon)]

This merge request was approved by Rémi Bernon.
-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/11002

[PATCH v2 0/2] MR11002: win32u: Enable VK_KHR_external_fence_capabilities in d3dkmt_init_vulkan(). - approved

[Elizabeth Figura (＠zfigura)]

This merge request was approved by Elizabeth Figura.
-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/11002