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