On Mon, Nov 5, 2018 at 7:12 AM Gert Wollny <gert.wol...@collabora.com> wrote: > > Am Donnerstag, den 01.11.2018, 12:32 -0400 schrieb Ilia Mirkin: > > > > > > 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. > BTW: why is it so hard to imagine that there is some GLES only hardware > out there that supports sRGB textures as framebuffer attachment, but > doesn't have a proper hardware interface to turn off encoding to sRGB > on write and allows changing this only by changing the attached texture > to a non-sRGB one?
There's no difference between the two extensions at the driver level -- the differences end at the GL API level. At the mesa driver level, it's a promise to look at ctx->Color.sRGBEnabled. At the gallium level, it's a promise that some PIPE_FORMAT_*_SRGB is supported for rendering and that you can use a non-srgb format in the surface even if the resource was originally allocated with an srgb format (and vice-versa). The latter bit is always a requirement for gallium drivers, of course. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev