| 18 Apr 2026 |
 K900 | Instead of trying to force an experimental Vulkan renderer on an experimental Vulkan driver | 11:24:21 |
 Randy Eckenrode | If MoltenVK doesn’t work, there may not be a better option. However, KosmicKrisp is not supported on Intel hardware. | 11:24:36 |
 WeetHet | It’s still used as default even if vulkan is available | 11:24:41 |
| WeetHet | On macOS | 11:24:52 |
| K900 | Then we should absolutely not pull in an experimental Vulkan driver automagically | 11:24:59 |
| K900 | If people want to opt into it for whatever reason, they can point the gun at their foot themselves | 11:25:16 |
| WeetHet | No, but if an app chooses to use vulkan it would be better if it used mesa and not moltenvk | 11:25:48 |
| K900 | Do you mean KosmicKrisp | 11:26:05 |
| K900 | Because "Mesa" is a lot of things | 11:26:10 |
| K900 | And it's important to make the distinction here | 11:26:15 |
| WeetHet | Yes but that’s longer to write | 11:26:19 |
| K900 | I think we should really wait for at least the LunarG SDKs to switch to kk by default | 11:26:49 |
| K900 | Are there actually any applications that force Vulkan on Darwin? | 11:27:10 |
| K900 | Because AFAIUI it is also considered experimental by GTK upstream | 11:27:29 |
| K900 | Even on Linux | 11:27:50 |
| WeetHet | The one I’m looking to finally package would because the GL performance is horrendous on macOS | 11:27:57 |
| K900 | Then you should probably apply that per-application, with an explicit comment stating why this is being done, what issue is being worked around, and that it should be reverted once kk is default and Vulkan is the default backend for GTK on Darwin | 11:29:14 |
| K900 | I absolutely don't think that pulling an experimental driver into every single GTK application's closure just because someone might do a thing that they have been explicitly told not to is reasonable | 11:29:32 |
| WeetHet | There are 3 issues right now:
- Gtk isn’t even being built with vulkan support on macOS
- Moltenvk causes artifacts when vulkan backend is used (https://gitlab.gnome.org/GNOME/gtk/-/issues/7595)
- If we enable vulkan support but don’t use KosmikKrisp by default people might expect it to work well which is an incorrect assumption
| 11:32:30 |
| K900 | Again, upstream GTK explicitly says that the Vulkan backend is experimental | 11:33:04 |
| K900 | If people expect it to work well, that's on them | 11:33:09 |
| Randy Eckenrode | Can Vulkan support be built but not enabled by default? | 11:33:23 |
| WeetHet | Yes | 11:33:34 |
| Randy Eckenrode | That way, as K900 suggests, apps can opt in when needed. | 11:33:40 |
| K900 | Yes, that is what I'm saying | 11:34:12 |
| K900 | We can build Vulkan support | 11:34:12 |
| Randy Eckenrode | With appropriate TODOs to remove once that becomes the default. | 11:34:17 |
| K900 | That's not a problem | 11:34:13 |
| K900 | The part where I start having a problem is enabling it by default | 11:34:21 |
| K900 | Or pulling in kk into every GTK app closure because what if someone enables it | 11:34:44 |
