[Mesa-dev] [PATCH v6 0/8] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

Am Donnerstag, den 13.12.2018, 22:20 +0100 schrieb Erik Faye-Lund:
> On Thu, 2018-11-15 at 13:45 +0100, Gert Wollny wrote:
> > From: Gert Wollny <gert.wollny at collabora.com>
> > 
> > Dear all, 
> > 
> > after the RFC and Ilias comments I reworked the series another
> > time.  
> > Changes with respect to the RFC are 
> >   - renaming the new CAP 
> >   - reordering of the patches that no double checking of 
> >     EXT_sRGB and EXT_framebuffer_sRGB is needed. 
> > 
> > thanks for reviewing, 
> > Gert
> > 
> > Gert Wollny (8):
> >   Gallium: Add new CAPS to indicate whether a driver can switch
> > SRGB
> >     write
> >   virgl: Set sRGB write control CAP based on host capabilities
> >   mesa:main: Add flag for EXT_sRGB to gl_extensions
> >   i965: Set flag for EXT_sRGB
> >   mesa/st: rework support for sRGB framebuffer attachements
> >   mesa/main: Use flag for EXT_sRGB instead of EXT_framebuffer_sRGB
> > where
> >     possible
> >   mesa/main/version: Lower the requirements for GLES 3.0
> >   mesa/main: Expose EXT_sRGB_write_control
> > 
> 
> Hmm. So you only add a driver cap for EXT_sRGB, you don't actually
> expose the extension, right? I can't see it added to
> extensions_table.h...  Is there a reason for that?
> 
There are various reasons: 

EXT_sRGB is considered to be an incomplete extension.

> I guess it's more work than you'd want, considering it requires stuff
> like disallowing glGenerateMipmap() with sRGB textures...
This, and that this actually contradicts the GLES 3.0 spec. For drivers
that only support GLES 2.0 one could think about actually implementing
and exposing this extension, but AFAICS these are only some quite old
drivers. 

Another issue is that support for some more enums for texture creation
would have to be added and here I'm also not sure whether this should
be restricted to GLES 2.0. 

My original implementation for EXT_sRGB_write_control was a bit
different, but then Ilia pointed out that this is actually equivalent
to EXT_framebuffer_sRGB for all supported hardware with the notable
exception of virgl, and that's where the idea came from of adding this
flag for EXT_sRGB as a vehicle to expose GLES 3.0 if a virgl GLES host
doesn't support EXT_sRGB_write_control which is a requirement to expose
the extension it in the guest but not needed for GLES 3.0.

Best, 
Gert