[Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Marek Olšák]

At the Gallium level, you can change between UNORM and SRGB in
pipe_surface. If you allocate a texture as SRGB, you should be able to use
it as LINEAR and vice versa.

All hardware that supports both LINEAR and SRGB supports this. A typical hw
driver does that simply by changing the format in the framebuffer state.
The memory layout is always the same for RGBA 32bpp, so arbitrary changes
of formats are possible. There is no additional support needed in hw
because the format itself is a mutable state.

Marek

On Mon, Nov 5, 2018 at 11:02 AM Gert Wollny <gert.wollny at 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.
>
> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181105/b3404525/attachment.html>