[PATCH 0/2] MR11002: win32u: Enable VK_KHR_external_fence_capabilities in d3dkmt_init_vulkan().
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
From: Francisco Casas <fcasas@codeweavers.com> 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
From: Francisco Casas <fcasas@codeweavers.com> 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
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
participants (3)
-
Francisco Casas -
Francisco Casas (@fcasas) -
Henri Verbeet (@hverbeet)