On Tue Apr 7 01:06:55 2026 +0000, Elizabeth Figura wrote:
That's not what GL does. Note that init_srgb_formats() is not GL-specific code. Rather what's probably missing is support for SRGBWRITEENABLE and WINED3D_SAMP_SRGB_TEXTURE. 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 the major sRGB handling part 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 at a 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? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10567#note_135253