[PATCH 1/4] d3d9/tests: Test more formats in srgbtexture_test().

Henri Verbeet hverbeet at gmail.com
Wed Jan 22 10:39:03 CST 2020

On Wed, 22 Jan 2020 at 16:33, Paul Gofman <gofmanp at 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.

More information about the wine-devel mailing list