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

[Ilia Mirkin]

On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny <gert.wollny at collabora.com> 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 collabora.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?

BTW, I'd encourage you to forget about trying to express this in terms
of virgl host driver capabilities -- that's just a backend driver
(virgl) implementation detail, and thus irrelevant to the overall
"what does a backend need to be able to do" question.

Cheers,

  -ilia