We did previously not support this extension because it runs into 32bit alignment issues. But it is core in 1.3, so we already enabled the functionality. Additionally vkd3d-proton wants to use the extension and it does not care about 32bit.
Signed-off-by: Georg Lehmann dadschoorse@gmail.com --- dlls/winevulkan/make_vulkan | 1 - 1 file changed, 1 deletion(-)
diff --git a/dlls/winevulkan/make_vulkan b/dlls/winevulkan/make_vulkan index c609bbfd151..6e09f018b84 100755 --- a/dlls/winevulkan/make_vulkan +++ b/dlls/winevulkan/make_vulkan @@ -96,7 +96,6 @@ UNSUPPORTED_EXTENSIONS = [ "VK_AMD_display_native_hdr", "VK_EXT_full_screen_exclusive", "VK_EXT_hdr_metadata", # Needs WSI work. - "VK_EXT_pipeline_creation_feedback", "VK_GOOGLE_display_timing", "VK_KHR_external_fence_win32", "VK_KHR_external_semaphore_win32",
On Wed, 26 Jan 2022 at 17:35, Georg Lehmann dadschoorse@gmail.com wrote:
We did previously not support this extension because it runs into 32bit alignment issues. But it is core in 1.3, so we already enabled the functionality. Additionally vkd3d-proton wants to use the extension and it does not care about 32bit.
Shouldn't that have blocked 1.3 support instead?
On 26.01.22 17:37, Henri Verbeet wrote:
On Wed, 26 Jan 2022 at 17:35, Georg Lehmann dadschoorse@gmail.com wrote:
We did previously not support this extension because it runs into 32bit alignment issues. But it is core in 1.3, so we already enabled the functionality. Additionally vkd3d-proton wants to use the extension and it does not care about 32bit.
Shouldn't that have blocked 1.3 support instead?
Maybe. 32bit winevulkan has a ton of small issues, only exposing a non-broken subset is not really possible. E.g. VkPhysicalDeviceVulkan11Properties is also broken due to alignment and we don't ignore invalid pointers in a lot of situations where we should. We would not even be conformant for 1.0 without any extensions.
I think the best policy is to make everything work that is actually needed, there aren't a ton of 32bit Vulkan applications. It's mostly dxvk and possibly wined3d in the future as far as I understand.
The issue with VK_EXT_pipeline_creation_feedback will result in a misreported compile time duration, which is pretty minor in my opinion.
On Wed, 26 Jan 2022 at 18:02, Georg Lehmann dadschoorse@gmail.com wrote:
On 26.01.22 17:37, Henri Verbeet wrote:
On Wed, 26 Jan 2022 at 17:35, Georg Lehmann dadschoorse@gmail.com wrote:
We did previously not support this extension because it runs into 32bit alignment issues. But it is core in 1.3, so we already enabled the functionality. Additionally vkd3d-proton wants to use the extension and it does not care about 32bit.
Shouldn't that have blocked 1.3 support instead?
Maybe. 32bit winevulkan has a ton of small issues, only exposing a non-broken subset is not really possible. E.g. VkPhysicalDeviceVulkan11Properties is also broken due to alignment and we don't ignore invalid pointers in a lot of situations where we should. We would not even be conformant for 1.0 without any extensions.
But these issues aren't inherently unfixable or hard to fix, right?
I think the best policy is to make everything work that is actually needed, there aren't a ton of 32bit Vulkan applications. It's mostly dxvk and possibly wined3d in the future as far as I understand.
It's true that there aren't a lot of 32-bit Vulkan applications, but there certainly are a few. Current wined3d will indeed largely use the host Vulkan implementation directly, but that wouldn't be true for PE builds.
On 27.01.22 14:22, Henri Verbeet wrote:
On Wed, 26 Jan 2022 at 18:02, Georg Lehmann dadschoorse@gmail.com wrote:
On 26.01.22 17:37, Henri Verbeet wrote:
On Wed, 26 Jan 2022 at 17:35, Georg Lehmann dadschoorse@gmail.com wrote:
We did previously not support this extension because it runs into 32bit alignment issues. But it is core in 1.3, so we already enabled the functionality. Additionally vkd3d-proton wants to use the extension and it does not care about 32bit.
Shouldn't that have blocked 1.3 support instead?
Maybe. 32bit winevulkan has a ton of small issues, only exposing a non-broken subset is not really possible. E.g. VkPhysicalDeviceVulkan11Properties is also broken due to alignment and we don't ignore invalid pointers in a lot of situations where we should. We would not even be conformant for 1.0 without any extensions.
But these issues aren't inherently unfixable or hard to fix, right?
Nothing is inherently unfixable. Some issues depend on output pNext chain conversion handling, some others need manual written code to be conformant, like the invalid pointers in VkWriteDescriptorSet. (As a side note, wow64 will make this problem a lot worse, since we have to add struct conversion for all the members of VkGraphicsPipelineCreateInfo and that is a giant minefield of special rules for invalid pointers.)
The VK_EXT_pipeline_creation_feedback issue is a bit annoying because it's about an output struct inside an otherwise input pNext chain, so that definitely needs manual cleanup. I sent out a v2 patch set.
I think the best policy is to make everything work that is actually needed, there aren't a ton of 32bit Vulkan applications. It's mostly dxvk and possibly wined3d in the future as far as I understand.
It's true that there aren't a lot of 32-bit Vulkan applications, but there certainly are a few. Current wined3d will indeed largely use the host Vulkan implementation directly, but that wouldn't be true for PE builds.
-
Georg Lehmann -
Henri Verbeet