[PATCH 0/1] MR11538: win32u: Enable host Vulkan portability enumeration.
This change allows MoltenVK to be usable via the vulkan-loader. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538
From: Dean M Greer <38226388+Gcenx@users.noreply.github.com> --- dlls/win32u/vulkan.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/dlls/win32u/vulkan.c b/dlls/win32u/vulkan.c index 6feb6a0416e..4b3c9d98086 100644 --- a/dlls/win32u/vulkan.c +++ b/dlls/win32u/vulkan.c @@ -448,6 +448,11 @@ static VkResult convert_instance_create_info( struct mempool *pool, VkInstanceCr instance->obj.extensions.has_VK_EXT_surface_maintenance1 = 1; if (vulkan_funcs.host_extensions.has_VK_KHR_get_physical_device_properties2) instance->obj.extensions.has_VK_KHR_get_physical_device_properties2 = 1; + if (vulkan_funcs.host_extensions.has_VK_KHR_portability_enumeration) + { + instance->obj.extensions.has_VK_KHR_portability_enumeration = 1; + info->flags |= VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR; + } if (use_external_memory()) instance->obj.extensions.has_VK_KHR_external_memory_capabilities = 1; -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/11538
I don't think that's something win32u should be doing, at least not by default. Direct3D can, and I'd be willing to take a patch that does it despite the fact that Direct3D depends on a lot of those features. But the point of portability is that it removes assumptions that applications make about Vulkan. They need to explicitly opt in after making sure they can handle those missing pieces. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147418
On Fri Jul 31 01:00:42 2026 +0000, Elizabeth Figura wrote:
I don't think that's something win32u should be doing, at least not by default. Direct3D can, and I'd be willing to take a patch that does it despite the fact that Direct3D depends on a lot of those features. But the point of portability is that it removes assumptions that applications make about Vulkan. They need to explicitly opt in after making sure they can handle those missing pieces. If the Vulkan driver (MoltenVK in this case) can use Vulkan portability extensions then it’s enabled, if that’s not set MoltenVK can’t be used via the vulkan-loader.
Not sure why this should be within Direct3D when we want to be able to use Vulkan globally not just from within Direct3D? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147419
On Fri Jul 31 01:00:42 2026 +0000, Dean M Greer wrote:
If the Vulkan driver (MoltenVK in this case) can use Vulkan portability extensions then it’s enabled, if that’s not set MoltenVK can’t be used via the vulkan-loader. Not sure why this should be within Direct3D when we want to be able to use Vulkan globally not just from within Direct3D? This didn't affect the ability to use an x86_64 compile of kosmickrisp, part of the reason for wanting this to allow swapping between drivers without needing a recompile and be more standardizes across the board.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147420
On Fri Jul 31 01:00:42 2026 +0000, Dean M Greer wrote:
If the Vulkan driver (MoltenVK in this case) can use Vulkan portability extensions then it’s enabled, if that’s not set MoltenVK can’t be used via the vulkan-loader. Not sure why this should be within Direct3D when we want to be able to use Vulkan globally not just from within Direct3D? The portability "extension" is essentially the opposite of a usual extension in that it removes features. It is very specifically opt-in. By enabling the flag you are saying "I will not use the core 1.0 features that this driver does not support". We cannot guarantee that for arbitrary Vulkan applications [and for Direct3D specifically we should make an effort to replace any such code paths with FIXMEs]. It may be that those applications will work anyway, but that's the kind of thing that should hide behind a registry entry, that lets users know they get to keep the pieces when things break.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147478
On Fri Jul 31 15:11:38 2026 +0000, Elizabeth Figura wrote:
The portability "extension" is essentially the opposite of a usual extension in that it removes features. It is very specifically opt-in. By enabling the flag you are saying "I will not use the core 1.0 features that this driver does not support". We cannot guarantee that for arbitrary Vulkan applications [and for Direct3D specifically we should make an effort to replace any such code paths with FIXMEs]. It may be that those applications will work anyway, but that's the kind of thing that should hide behind a registry entry, that lets users know they get to keep the pieces when things break. Where at an annoying place as to use MoltenVK from the Vulkan-loader icd we’d need to set this or a default install MoltenVk icd won’t be usable due to it flagging itself `is_portability_driver`
With this set MoltenVK becomes a usable driver, I’d also tested asking KosmicKrisp by forcing the vulkan-loader to use the KosmicKrisp icd and it ran vkquake2 just fine. If the vulkan-loader itself set this needed bit when `is_portability_driver=true` then we’d already be in a good place. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147486
On Fri Jul 31 15:37:00 2026 +0000, Dean M Greer wrote:
Where at an annoying place as to use MoltenVK from the Vulkan-loader icd we’d need to set this or a default install MoltenVk icd won’t be usable due to it flagging itself `is_portability_driver` With this set MoltenVK becomes a usable driver, I’d also tested asking KosmicKrisp by forcing the vulkan-loader to use the KosmicKrisp icd and it ran vkquake2 just fine. If the vulkan-loader itself set this needed bit when `is_portability_driver=true` then we’d already be in a good place. What I am trying to say is that it is very intentionally not set by default. It is opt-in for a reason. Setting it by default might make some applications work out of the box, but others will be broken. For that reason I think it is reasonable to hide it behind a registry key, but enabling it by default is not the correct thing to do.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147488
On Fri Jul 31 16:08:06 2026 +0000, Elizabeth Figura wrote:
What I am trying to say is that it is very intentionally not set by default. It is opt-in for a reason. Setting it by default might make some applications work out of the box, but others will be broken. For that reason I think it is reasonable to hide it behind a registry key, but enabling it by default is not the correct thing to do. I understand the principle, but in practice it feels like a regression.
Currently it’s common for Wine to use MoltenVK directly without the loader (CrossOver does, I believe @Gcenx’s builds also do), this results in apps using MoltenVK whether they opt-in to portability or not. With KosmicKrisp becoming an option using the Vulkan loader will be common, and it’s unfortunate if using MoltenVK with the loader requires extra configuration or out-of-tree patches vs. the current status quo of using it directly. In addition, are there any Windows Vulkan apps/games that opt-in to portability? I thought it basically exists only for MoltenVK, in that case I wouldn’t expect any Windows app (other than Wine’s own components) to ever specify it. Requiring applications to opt-in when we know that none do or ever will feels like correctness to a fault. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147499
On Fri Jul 31 17:40:57 2026 +0000, Brendan Shanks wrote:
I understand the principle, but in practice it feels like a regression. Currently it’s common for Wine to use MoltenVK directly without the loader (CrossOver does, I believe @Gcenx’s builds also do), this results in apps using MoltenVK whether they opt-in to portability or not. With KosmicKrisp becoming an option using the Vulkan loader will be common, and it’s unfortunate if using MoltenVK with the loader requires extra configuration or out-of-tree patches vs. the current status quo of using it directly. In addition, are there any Windows Vulkan apps/games that opt-in to portability? I thought it basically exists only for MoltenVK, in that case I wouldn’t expect any Windows app (other than Wine’s own components) to ever specify it. Requiring applications to opt-in when we know that none do or ever will feels like correctness to a fault. So what was the point of MoltenVK actually using this flag as intended in the first place, then?
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147503
On Fri Jul 31 18:35:02 2026 +0000, Elizabeth Figura wrote:
So what was the point of MoltenVK actually using this flag as intended in the first place, then? @zfigura upstream wants is_portability_driver=true set for MoltenVK as it’s not fully Vulkan conformant.
Sadly this also means that MoltenVK won’t load as the expected flag isn’t set at creation. @bshanks The only solution I’ve come up with that doesn’t request this or other awful hacks is setting is_portability_driver=false within the bundled MoltenVK_icd.json I can then tell the vulkan-loader to ignore MoltenVK or force load a custom icd that points to KosmicKrisp (or another a patched MoltenVK) I’ve been getting asked a lot to build wine against the vulkan-loader -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147504
On Fri Jul 31 19:07:11 2026 +0000, Dean M Greer wrote:
@zfigura upstream wants is_portability_driver=true set for MoltenVK as it’s not fully Vulkan conformant. Sadly this also means that MoltenVK won’t load as the expected flag isn’t set at creation. @bshanks The only solution I’ve come up with that doesn’t request this or other awful hacks is setting is_portability_driver=false within the bundled MoltenVK_icd.json I can then tell the vulkan-loader to ignore MoltenVK or force load a custom icd that points to KosmicKrisp (or another a patched MoltenVK) I’ve been getting asked a lot to build wine against the vulkan-loader I mean, if the ecosystem as a whole is going to hang on to the idea that a technically correct and fully specified Vulkan is what we want, then I don't see any reason why Wine shouldn't be a part of that, even if I personally think it was a fool's errand. Like, "correctness to a fault" was *always* the design philosophy behind Vulkan, no?
If we're going to second-guess the ecosystem, I can't complain too much, although it at least deserves a note saying that we're doing so (and maybe even a winediag err if we find we are using a portability-only driver), because otherwise this code just looks wrong. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147507
On Fri Jul 31 20:25:05 2026 +0000, Elizabeth Figura wrote:
I mean, if the ecosystem as a whole is going to hang on to the idea that a technically correct and fully specified Vulkan is what we want, then I don't see any reason why Wine shouldn't be a part of that, even if I personally think it was a fool's errand. Like, "correctness to a fault" was *always* the design philosophy behind Vulkan, no? If we're going to second-guess the ecosystem, I can't complain too much, although it at least deserves a note saying that we're doing so (and maybe even a winediag err if we find we are using a portability-only driver), because otherwise this code just looks wrong. Did a bit more digging into vulkan-loader and it doesn't pass `VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR` to the icd if it sets `is_portability_driver=false` so enabling it by default should be an none issue and also means the vulkan-loader will see MoltenVK as a valid icd.
See https://github.com/KhronosGroup/Vulkan-Loader/commit/192efa48a79b0f2d9f7f16f... And the section is still the same in main https://github.com/KhronosGroup/Vulkan-Loader/blob/06830240f7a70599053f47b5f... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147550
On Sat Aug 1 12:06:23 2026 +0000, Dean M Greer wrote:
Did a bit more digging into vulkan-loader and it doesn't pass `VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR` to the icd if it sets `is_portability_driver=false` so enabling it by default should be an none issue and also means the vulkan-loader will see MoltenVK as a valid icd. See https://github.com/KhronosGroup/Vulkan-Loader/commit/192efa48a79b0f2d9f7f16f... And the section is still the same in main https://github.com/KhronosGroup/Vulkan-Loader/blob/06830240f7a70599053f47b5f... If the icd doesn't set `is_portability_driver` at all it's treated as `is_portability_driver=false` so setting it by default looks like it'll be a none issue.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147555
So what was the point of MoltenVK actually using this flag as intended in the first place, then?
Since native Vulkan-using Mac apps bundle their own copy of MoltenVK and the loader, apps predating the portability extensions just keep working. Only when they update to a new-enough loader and MoltenVK do they need to start using `portability_enumeration` (and the developer has control over all those pieces). ([LunarG white paper](https://www.lunarg.com/wp-content/uploads/2022/04/Portability-Enumeration-Ex...)) Of course this falls apart with Wine, we're using a single version of the loader to run an unbounded set of Windows Vulkan applications, none of which have any reason to use `portability_enumeration`. I think it's fine to have a WARN or winediag ERR when a portability driver is being used (I guess this would be when `vkCreateDevice()` is called on a device that implements `VK_KHR_portability_subset`?). We'd want to ensure that this doesn't get printed for any instance which actually opts-in to portability_enumeration (i.e. we don't want win32u's own Vulkan GPU enumeration in `d3dkmt_init_vulkan()` to trigger this warning on every launch). Also, maybe this change should be `#ifdef __APPLE__`? Just to avoid affecting any other platforms and make it clear that we're only doing this for MoltenVK. (I don't believe there are any other portability drivers anyway). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11538#note_147944
participants (4)
-
Brendan Shanks (＠bshanks) -
Dean M Greer
-
Dean M Greer (＠Gcenx)
-
Elizabeth Figura (＠zfigura)