| 18 Apr 2026 |
 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 |
| K900 | If you have an application that specifically has issues with the GL backend and not Vulkan/kk, you should force it in the specific wrapper for that application, and then you have local ownership of that decision | 11:35:26 |
| WeetHet | Would you prefer if the vulkan build used KK or moltenvk by default? | 11:35:59 |
| K900 | I would prefer it used vulkan-loader and not cared about what driver is on the backend | 11:37:21 |
| K900 | So that decision can be made in vulkan-loader when the time comes | 11:37:31 |
| WeetHet | Then it would use moltenvk by default | 11:38:33 |
| WeetHet | Because that is what is hardcoded into the vulkan loader | 11:39:08 |
| Randy Eckenrode | That’s fine. Apps that opt in can document why and what they are doing. | 11:40:34 |
|  hgl joined the room. | 14:03:24 |
|  @enzime:nixos.dev joined the room. | 14:04:30 |
| @enzime:nixos.dev left the room. | 14:04:41 |
| Randy Eckenrode | nodejs-slim seems to be really broken on staging on Darwin. | 17:43:54 |
