On Wed, 22 Jan 2020 at 16:33, Paul Gofman gofmanp@gmail.com wrote:
On 1/22/20 15:54, Stefan Dösinger wrote:
I like the idea of enabling that fallback, although I am not sure what's the cleanest way though. I guess a pile of gl_info->supported[EXT_TEXTURE_SRGB_DECODE] could be replaced by format.internal == format.sRGB_internal checks. The assignment logic if EXT_TEXTURE_SRGB_DECODE needs to be adjusted to just do it for formats with native support, while still allowing advertising the format as supported to the game. There are also potential pitfalls with FRAMEBUFFER_sRGB. Afaik we advertise sRGB write correction only if we can do EXT_TEXTURE_SRGB_DECODE switching because FRAMEBUFFER_sRGB only works on sRGB internal formats.
I'm sure you'll figure something out :-)
I guess a change to needs_separate_srgb_gl_texture() in wined3d_private.h involving the format check will act as a main trigger for fallback logic. Then I need to surf through each EXT_TEXTURE_SRGB_DECODE and d3d_info->srgb_read_control check to see what needs to be adjusted on case by case basis. I don't think its a lot, as mostly these checks affect setting GL_TEXTURE_SRGB_DECODE_EXT GL sampler parameter which has no effect on non SRGB format anyway.
I suspect it's not worth it in terms of making the code more complex; it isn't all that straightforward to start with, as you've found. I'm tempted to just take the hit of using GL_SRGB8 for these formats, unfortunate as that may be.