On Tue Apr 7 11:12:24 2026 +0000, Stian Low wrote:
Thanks for taking a look. GL handling of sRGB is not so trivial so I may have misstated how it actually works. From what I've gathered so far, `init_srgb_formats()` copies UNORM `wine_format` data to sRGB but maintains a unique IDs for sRGB for later processing depending on some criteria for checking for GL sRGB support. `struct wined3d_format_texture_info gl_srgb_internal` is used by `init_format_texture_info()` which seems to handle sRGB missing for `wined3d_adapter_vk_init_format_info()`. Perhaps `init_format_texture_info()` for GL sRGB needs be implemented for VK within `init_vulkan_format_info()`? At the very least it would handle UNORM sRGB format mapping more granular than the more trivial and probably less robust swapchain level provided by the latest patch. Its unclear for now how to support sRGB handling for VK via SRGBWRITEENABLE and WINED3D_RS_SRGBWRITEENABLE so I'll have to take a closer look. `shader_glsl_apply_draw_state()` calls `state_srgbwrite()` with param `WINED3D_RS_SRGBWRITEENABLE` but that param is not used by `srgbwrite()` which just calls `glEnable/glDisable()` for `GL_FRAMEBUFFER_SRGB` depending on `wined3d_state` param. For VK, framebuffer attachmment VK_FORMAT may just need to be set correctly for UNORM vs sRGB so maybe wined3d_state is less applicable for VK than GL? In d3d9, sRGB colour space conversion is something you toggle on and off when drawing. In GL and Vulkan, it's instead implemented using different formats, which do colour space conversion when bound. This means that an application can toggle sRGB and cause the data in the same texture to be interpreted as sRGB or linear.
In order to implement this in otherwise unextended GL, we need to potentially keep two different textures around, and to reinterpret, we download a texture to the CPU and then upload the same data to the other texture. This is slow and a bit cumbersome, and so if we have EXT_texture_sRGB_decode and EXT_framebuffer_sRGB, we can instead use a single sRGB texture and simply toggle between whether it's interpreted as sRGB and linear. (The former extension was actually motivated by D3D and you'll notice a familiar name on the authors list.) The same functionality is available in d3d10+, later GL, and Vulkan by using views. Views can generally arbitrarily reinterpret data as any other data as long as it takes up the same amount of space. Reinterpreting sRGB data as linear data is a case of this. So what we need to do for Vulkan is to create and bind linear views for sRGB textures as needed, probably from within stateblock.c.
From what I've gathered so far, `init_srgb_formats()` copies UNORM `wine_format` data to sRGB but maintains a unique IDs for sRGB for later processing depending on some criteria for checking for GL sRGB support.
It's precomputing a bunch of information about formats so it can be quickly looked up later. Since sRGB formats are almost identical to their non-sRGB equivalents, most of that information ends up being copied.
`struct wined3d_format_texture_info gl_srgb_internal` is used by `init_format_texture_info()` which seems to handle sRGB missing for `wined3d_adapter_vk_init_format_info()`.
That's for the old style sRGB emulation, which we don't need for Vulkan.
Perhaps `init_format_texture_info()` for GL sRGB needs be implemented for VK within `init_vulkan_format_info()`? At the very least it would handle UNORM sRGB format mapping more granular than the more trivial and probably less robust swapchain level provided by the latest patch.
All of that functionality is handled pretty much directly in init_vulkan_format_info(). See, GL format detection is a very complicated beast, because the idea of "just ask the driver whether this operation is supported" (i.e. ARB_internalformat_query, but actually we need ARB_internalformat_query2 for most things) wasn't always around, so we essentially have a huge hardcoded list of format capabilities based on what's supposed to be guaranteed by extensions. That then gets complicated by having to support different fallbacks for certain formats, including the sRGB stuff. We go to some extreme lengths to get cards to support the same level of d3d functionality as they do on Windows. With Vulkan it's a lot easier, because we just have format feature queries, not to mention almost everything we need is baked into version 1.0, so we don't need all those fallbacks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10567#note_135303