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

[Ilia Mirkin]

On Thu, Nov 1, 2018 at 12:17 PM Gert Wollny <gert.wollny at collabora.com> wrote:
>
> Am Donnerstag, den 01.11.2018, 12:03 -0400 schrieb Ilia Mirkin:
> > On Thu, Nov 1, 2018 at 11:45 AM Gert Wollny <gert.wollny at collabora.co
> > m> wrote:
> > >
> > > Am Donnerstag, den 01.11.2018, 11:19 -0400 schrieb Ilia Mirkin:
> > > > On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny <gert.wollny at collabor
> > > > a.co
> > > > m> wrote:
> > > > >
> > > > > Am Donnerstag, den 01.11.2018, 10:34 -0400 schrieb Ilia Mirkin:
> > > > > > On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny <gert.wollny at coll
> > > > > > abor
> > > > > > a.co
> > > > > > m> wrote:
> > > > > > >
> > > > > > > Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia
> > > > > > > Mirkin:
> > > > > > > > So ... thinking about this a little more ... how is the
> > > > > > > > new
> > > > > > > > enable
> > > > > > > > different from the existing "EXT_framebuffer_sRGB"
> > > > > > > > enable?
> > > > > > > > When
> > > > > > > > would
> > > > > > > > one be set but not the other?
> > > > > > >
> > > > > > > This one is a GLES extension, there, if the surface
> > > > > > > attached to
> > > > > > > a
> > > > > > > framebuffer is sRGB capable, it behaves always like
> > > > > > > glEnable(GL_FRAMEBUFFER_SRGB) is set. With this extension,
> > > > > > > control
> > > > > > > is
> > > > > > > given back to the application. To keep compatibility, the
> > > > > > > default
> > > > > > > is
> > > > > > > still the same behaviour as without the extension (which is
> > > > > > > different
> > > > > > > from desktop GL).
> > > > > >
> > > > > > Yeah, I get that the details of ext itself are different. I'm
> > > > > > talking
> > > > > > about the enable bit -- would one ever be set but not the
> > > > > > other?
> > > > > > If
> > > > > > so, why have two bits?
> > > > >
> > > > > If a virglrenderer GLES host driver doesn't support the
> > > > > extension,
> > > > > then
> > > > > mesa/virgl can not expose the it (I tried it, it doesn't pass
> > > > > the
> > > > > tests), so there you would have EXT_framebuffer_sRGB, but not
> > > > > EXT_sRGB_write_control.
> > > >
> > > > So what does a (mesa backend) driver need to be able to do to
> > > > support
> > > > EXT_sRGB_write_control on top of what's needed for
> > > > EXT_framebuffer_sRGB?
> > > >
> > >
> > > If I attach an sRGB surface to a framebuffer on GLES, then, in
> > > order
> > > to support EXT_sRGB_write_control, the backend must be able switch
> > > on
> > > and off the linear-sRGB conversion on writes to this attachment.
> >
> > Is that different from what's needed to support
> > glEnable/glDisable(GL_FRAMEBUFFER_SRGB) in desktop GL's
> > EXT_framebuffer_sRGB?
>
> It is not different, this extension was specifically written to bring
> GLES on par with GL in this asspect (although with a different
> default). That said, there might be GLES only hardware that
> supports EXT_framebuffer_sRGB but does not support
> EXT_sRGB_write_control, and for these cases you need an extra flag. I
> mean there must be a reason why the GLES spec doesn't require
> EXT_sRGB_write_control ...

EXT_framebuffer_sRGB is a desktop GL ext. EXT_sRGB_write_control is a
GLES ext that was meant to provide the same functionality in GLES
(have a glance at Issue #1 in that spec). You could have hardware that
supports neither, or hardware that supports both. The differences
appear to be at the API level, not at the hardware capability level.

Cheers,

  -ilia