Am 22.01.20 um 13:44 schrieb Paul Gofman:
Oh yeah, thanks. So maybe I introduce that fallback code path for 16 bit SRGB formats then? Or fixup the colour in GLSL (this looks more messy to me at the first glance, not sure it worth adding an extra shader setting for that at the first place and also it will further complicate SRGB handling logic)? Or ignore that bug for now as there is anyway a workaround possible by faking AMD card through registry?
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 :-)
GLSL seems overkill. It would add extra shader state logic that seems more complicated than changing the texture format code. Ignoring a bug is always ugly.