[PATCH 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.

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

[PATCH 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, that requires enabling the
VK_KHR_external_fence_capabilities instance extension.

Otherwise we get the following validation layer error:

    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)
---
 dlls/win32u/d3dkmt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/dlls/win32u/d3dkmt.c b/dlls/win32u/d3dkmt.c
index 38624583f7d..0c93774e186 100644
--- a/dlls/win32u/d3dkmt.c
+++ b/dlls/win32u/d3dkmt.c
@@ -491,6 +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_fence_capabilities = 1,
         .has_VK_KHR_external_memory_capabilities = 1,
     };
 
-- 
GitLab


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

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

[Francisco Casas]

From: Francisco Casas <[e-mail]>

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

It is required to fill the VkPhysicalDeviceIDProperties struct when
calling vkGetPhysicalDeviceProperties2().
---
 dlls/wined3d/adapter_vk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/dlls/wined3d/adapter_vk.c b/dlls/wined3d/adapter_vk.c
index 55c7b167156..9123dceaebc 100644
--- a/dlls/wined3d/adapter_vk.c
+++ b/dlls/wined3d/adapter_vk.c
@@ -1933,6 +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_FENCE_CAPABILITIES_EXTENSION_NAME,      VK_API_VERSION_1_1, FALSE},
     {VK_KHR_EXTERNAL_MEMORY_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

[Henri Verbeet (＠hverbeet)]

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

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 suspect the win32u usage of the same extension similarly originates from commit dd25789fb24e257baea4b257deddad44d5b6fedd, but I didn't verify that. Ideally the validation layers would get fixed, but if we want to work around them, we should be able to replace VK_KHR_external_memory_capabilities with VK_KHR_external_fence_capabilities in at least wined3d, and possibly in win32u as well.

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