[Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Ilia Mirkin]

On Mon, Nov 5, 2018 at 11:02 AM Gert Wollny <gert.wollny at collabora.com> wrote:
>
> Am Montag, den 05.11.2018, 08:56 -0500 schrieb Ilia Mirkin:
> > At the gallium level, it's a promise that some PIPE_FORMAT_*_SRGB is
> > supported for rendering and that you can use a non-srgb format in the
> > surface even if the resource was originally allocated with an srgb
> > format (and vice-versa). The latter bit is always a requirement for
> > gallium drivers, of course.
>
> How so? What if the hardware does not support using a non-srgb format
> if the resource was originally allocated with an srgb format?
> You might not like it when I bring this example, but if a virglrenderer
> GLES host driver doesn't support EXT_sRGB_write_control, then we have
> exactly this example: the "hardware" is missing the option to flip a
> bit that makes it possible to use a non-srgb format with a resource
> that was allocated with an srgb format, but it still supports some SRGB
> formats, and since Gallium enables EXT_framebuffer_sRGB based on these
> I can not simply use the EXT_framebuffer_sRGB flag to expose
> EXT_sRGB_write_control.

The scenario you describe is not representable using current internal
API's/settings. We use bind flags (in Gallium) to determine if a
format is renderable or not. There is no "oh, it's renderable if this,
but not if that". Have a look at e.g. st_cb_texture.c, it will happily
blit as RGBA8_UNORM instead of RGBA8_SRGB, which will break your
scheme.

This use-case is just not supported right now. If you'd like to add
support for it, that's fine too -- however it's a lot more than a
single enable flag. You have to pipe it all the way through, and
adjust the (internal) users to respect it.

I'd say the expedient thing for now is if a GLES host doesn't support
EXT_sRGB_write_control, don't expose any SRGB formats at all.

Cheers,

  -ilia