On Mon, Nov 5, 2018 at 11:02 AM Gert Wollny <gert.wol...@collabora.com> wrote: > > Am Montag, den 05.11.2018, 08:56 -0500 schrieb Ilia Mirkin: > > 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. > > How so? What if the hardware does not support using a non-srgb format > if the resource was originally allocated with an srgb format? > You might not like it when I bring this example, but if a virglrenderer > GLES host driver doesn't support EXT_sRGB_write_control, then we have > exactly this example: the "hardware" is missing the option to flip a > bit that makes it possible to use a non-srgb format with a resource > that was allocated with an srgb format, but it still supports some SRGB > formats, and since Gallium enables EXT_framebuffer_sRGB based on these > I can not simply use the EXT_framebuffer_sRGB flag to expose > EXT_sRGB_write_control.
The scenario you describe is not representable using current internal API's/settings. We use bind flags (in Gallium) to determine if a format is renderable or not. There is no "oh, it's renderable if this, but not if that". Have a look at e.g. st_cb_texture.c, it will happily blit as RGBA8_UNORM instead of RGBA8_SRGB, which will break your scheme. This use-case is just not supported right now. If you'd like to add support for it, that's fine too -- however it's a lot more than a single enable flag. You have to pipe it all the way through, and adjust the (internal) users to respect it. I'd say the expedient thing for now is if a GLES host doesn't support EXT_sRGB_write_control, don't expose any SRGB formats at all. Cheers, -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
