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

[Gert Wollny]

Am Dienstag, den 06.11.2018, 15:28 -0500 schrieb Ilia Mirkin:
> On Tue, Nov 6, 2018 at 3:15 PM Gert Wollny <gert.wollny at collabora.com
> > wrote:
> > 
> > 
> > The extension has the status "not complete" but after reading is it
> > seems to describe what is needed from ARB_framebuffer_sRGB in GLES
> > 3.0, 

Well, after starting to hacking it up and reading the finer details  it
turns out that EXT_sRGB is not providing what GLES 3.0 needs: 

EXT_sRGB says 
"""
Accepted by the <format> and <internalformat> parameter of TexImage2D,
and     TexImage3DOES.  These are also accepted by <format> parameter
of TexSubImage2D and TexSubImage3DOES:

    SRGB_EXT                                       0x8C40
    SRGB_ALPHA_EXT                                 0x8C42
    
Accepted by the <internalformat> parameter of RenderbufferStorage:

    SRGB8_ALPHA8_EXT                               0x8C43
"""

whereas GLES 3.0 only knows the internal formats  SRGB8 and
SRGB8_ALPHA8 but it doesn't use the unsized SRGB_EXT and SRGB_ALPHA_EXT
at all, and certainaly not as accepted formats. 

Also there is 

"""
 4) What is the expectation for mipmap generation on SRGB textures?
Issue 24 from EXT_texture_sRGB gives two possible ways, will we leave
it similarly undefined, or is this not intended to be supported at all?
 
No.  This in not likely to be used much so for simplicity let's not
require it.  This will generate an INVALID_OPERATION error.
"""

which is also in conflict with GLES 3.0. 

Which brings me back to what I was talking about yesterday: For
properly calculating GLES 3.0 support a flag is needed that says sRGB
render targets are supported without the need that such a fbo
attachment can switch between linear and sRGB.

Well, I'll think of something and send an RFC 

Best, 
Gert