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. Apart from that and as I pointed out before, IMHO using a different flag for the two things is better for code readability, and using one byte more in a structure that is not passed around in a runtime- critical code path is a little price to pay for making it easier for the next person to understand the code. Best, Gert _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
