[Mesa-dev] glBlitFramebuffer and sRGB vs piglit

[Henri Verbeet]

On 16 December 2013 01:37, Marek Olšák <maraeo at gmail.com> wrote:
> Hi everybody,
>
> There is an inconsistence in the piglit glBlitFramebuffer tests. If
> both src and dst are sRGB, piglit expects this from glBlitFramebuffer:
>
> if (dst.num_samples == 1 && src.num_samples > 1) {
>    enable the sRGB->linear conversion for src reads
>    and the linear->sRGB conversion for dst writes;
> }
> else {
>    disable the sRGB conversions;
> }
>
> Is this the intended behavior?
> Regardless of the GL spec, what behavior do applications expect? (if
> somebody knows)
>
As far as Wine is concerned, the assumption is that FBO blits don't do
colorspace conversion. The current piglit / Mesa behaviour is
consistent with that. Doing filtering in sRGB color space (which is
pretty much what the first case you mentioned amounts to) also makes
sense, although for the case where you have an sRGB internal format
with SKIP_DECODE (from EXT_texture_sRGB_decode) it's not necessarily
correct.

The above is pretty much the de facto standard pre-4.4, and even if
the spec perhaps doesn't explicitly specify that behaviour, I think it
strongly hints in that direction.

> Also most of the piglit BlitFramebuffer tests with sRGB formats expect
> the opposite than what GL 4.4 specifies, and if we implemented the GL
> 4.4 behavior, all those tests would fail.
>
> For reference, GL 4.4 requires this:
> - if src.format is sRGB, do the sRGB->linear conversion for reads. (I
> think it can only be disabled with texture views.)
> - if dst.format is sRGB and GL_FRAMEBUFFER_SRGB is enabled, do the
> linear->sRGB conversion for dst writes.
>
> st/mesa does this:
> - Always disable the sRGB conversions.
>
> I think the older GL specs specify a different behavior for sRGB
> blits, which roughly corresponds to how st/mesa does it. Yeah, it's a
> pretty messy situation. So, do you have any answers to the 2 questions
> above?
>
If I were to guess at intention, it seems that in 4.4 you're supposed
to use texture views instead of sRGB decode for enabling / disabling
sRGB read conversion, and in that case you would have full control
over enabling both read and write sRGB conversion for blits, and
implicitly over in what color space filtering happens.

I do think 4.4 breaks compatibility with earlier versions here, if not
officially at least de facto. I also think that without texture views
the 4.4 behaviour doesn't make nearly as much sense. My vote would be
to keep the current behaviour for anything pre-4.4. Where that gets
messy is probably compatibility contexts, but my understanding is that
Mesa has no intention of (ever?) implementing those.