[Mesa-dev] [PATCH 1/3] meta: Implement sensible behavior for BlitFramebuffer with sRGB.

Henri Verbeet hverbeet at gmail.com
Wed Aug 1 03:50:12 PDT 2012


On 1 August 2012 03:04, Eric Anholt <eric at anholt.net> wrote:
> Prior to GL 4.2 spec, there was no guidance on how to implement
> BlitFramebuffer for sRGB.  Mesa chose to implement skipping decode and encode,
> providing a reasonable behavior for sRGB -> sRGB or RGB -> RGB, but providing
> something absurd for mixing and matching the two.
>
> In GL 4.2, some text appeared in the spec saying to skip decode (search for
> "no linearization").  The only non-absurd interpretation of that would be to
> have no encode (same as Mesa's current implementation), otherwise sRGB -> sRGB
> blits wouldn't work.
>
> However, it seems clear that you should be able to blit sRGB to RGB and RGB to
> sRGB and get appropriate conversion.  The ARB has been discussing the issue,
> and appears to agree.  So, instead implement the same behavior as gallium, and
> always do the decode if the texture is sRGB, and do the encode if the
> application asked for it.
>
> Breaks piglit fbo-srgb-blit, which was expecting our previous no-conversion
> behavior.
> ---
Issue 12 in EXT_texture_sRGB requires no conversion on FBO blits,
because they're mostly specified in terms of CopyPixels.
EXT_framebuffer_sRGB has similar language in issue 8.


More information about the mesa-dev mailing list