Hi!
I have been looking into the dEQP test failures that deal with blitting
between sRGB and linear color spaces, and vice versa (in total 37
tests).
OpenGL ES 3.0 and OpenGL 4.4 specifications clearly state that
linearization should happen when reading from sRGB buffers, and sRGB
encoding should be done when writing to sRGB buffers during the blit
operation. In the case OpenGL 4.4 specification this encoding/decoding
is dependent on the value of the GL_FRAMEBUFFER_SRGB enable flag; OpenGL
ES 3.0 acts as if this setting was always enabled.
- From section 4.3.3 ("Copying Pixels") of the OpenGL ES 3.0
specification (page 198):
"When values are taken from the read buffer, if the value of
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer
attachment corresponding to the read buffer is SRGB (see section
6.1.13), the red, green, and blue components are converted from
the non-linear sRGB color space according to equation 3.24.
When values are written to the draw buffers, blit operations
bypass the fragment pipeline. The only fragment operations which
affect a blit are the pixel ownership test, the scissor test,
and sRGB conversion (see section 4.1.8). Color, depth, and
stencil masks (see section 4.2.2) are ignored."
- From section 18.3.1 ("Blitting Pixel Rectangles") of the OpenGL 4.4
core specification (page 485):
"When values are taken from the read buffer, if FRAMEBUFFER_SRGB
is enabled and the value of
FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer
attachment corresponding to the read buffer is SRGB (see section
9.2.3), the red, green, and blue components are converted from
the non-linear sRGB color space according to equation 8.14.
When values are written to the draw buffers, blit operations
bypass most of the fragment pipeline. The only fragment
operations which affect a blit are the pixel ownership test, the
scissor test, and sRGB conversion (see section 17.3.9). Color,
depth, and stencil masks (see section 17.4.2) are ignored."
However, the implementation in Mesa preserves the underlying binary
representation of the pixels,
regardless the color space. This is related to the fact that the OpenGL
4.3 specification was not consistent regarding blits involving sRGB
buffers; for more information see [1]. Apart from this, it was suggested
in some comments in the code (specifically comments [1] and [2]), that
existing games and applications rely on the current behaviour, not
expecting sRGB encoding/decoding to be done.
In summary, the current implementation does not respect the OpenGL 4.4
and OpenGL ES 3.0 specs, however, it seems to be the implementation that
some applications / games expect, so it is unclear to me if we want to
re-implement this according to what the specs dictate or leave it as it
is now. Any thoughts?
Regards.
[1] Piglit: comments in tests/spec/arb_framebuffer_srgb/blit.c source
file and the log of the commit abd189966d39648c00f3204c58fef217e94a8703
[2] Mesa: comments in src/mesa/drivers/common/meta_blit.c source file
("blitframebuffer_texture" function).
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
