On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny <gert.wol...@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.wol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
