diff options
author | Kenneth Graunke <[email protected]> | 2016-08-02 11:04:01 -0700 |
---|---|---|
committer | Kenneth Graunke <[email protected]> | 2016-08-08 14:01:51 -0700 |
commit | cc27c7fe38dde3cfde30eb88dd5088b139d71f26 (patch) | |
tree | c8ea9b6108c6157d6368efb694cedc623282b5ef | |
parent | b1586526e84ab6eab2023b589da8e153f70dda50 (diff) |
i965: Drop the "do resolves in sRGB" hack.
I've never quite understood the purpose of this hack - supposedly,
doing resolves in the sRGB colorspace is slightly more accurate.
Currently, BlitFramebuffer() ignores sRGB encoding and decoding
on OpenGL, although it encodes and decodes in GLES 3.x.
The updated OpenGL 4.4 rules also allow for encoding and decoding
if GL_FRAMEBUFFER_SRGB is enabled, allowing the application to
control what colorspace blits are done in. I don't think this hack
makes any sense in such a world - the application can do what it
wants, and we shouldn't second guess them.
A related Piglit patch, "Make multisample accuracy test set
GL_FRAMEBUFFER_SRGB when resolving." makes the Piglit MSAA accuracy
test explicitly request SRGB encoding/decoding during resolves when
running "srgb" subtests. Without that patch, this commit will regress
those tests, but with it, they should continue to work just fine.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
-rw-r--r-- | src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 24 |
1 files changed, 0 insertions, 24 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp index a54680e5b6b..7532aac118d 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp @@ -1659,30 +1659,6 @@ brw_blorp_blit_miptrees(struct brw_context *brw, brw_blorp_surface_info_init(brw, ¶ms.dst, dst_mt, dst_level, dst_layer, dst_format, true); - /* Even though we do multisample resolves at the time of the blit, OpenGL - * specification defines them as if they happen at the time of rendering, - * which means that the type of averaging we do during the resolve should - * only depend on the source format; the destination format should be - * ignored. But, specification doesn't seem to be strict about it. - * - * It has been observed that mulitisample resolves produce slightly better - * looking images when averaging is done using destination format. NVIDIA's - * proprietary OpenGL driver also follow this approach. So, we choose to - * follow it in our driver. - * - * When multisampling, if the source and destination formats are equal - * (aside from the color space), we choose to blit in sRGB space to get - * this higher quality image. - */ - if (params.src.num_samples > 1 && - _mesa_get_format_color_encoding(dst_mt->format) == GL_SRGB && - _mesa_get_srgb_format_linear(src_mt->format) == - _mesa_get_srgb_format_linear(dst_mt->format)) { - assert(brw->format_supported_as_render_target[dst_mt->format]); - params.dst.brw_surfaceformat = brw->render_target_format[dst_mt->format]; - params.src.brw_surfaceformat = brw_format_for_mesa_format(dst_mt->format); - } - /* When doing a multisample resolve of a GL_LUMINANCE32F or GL_INTENSITY32F * texture, the above code configures the source format for L32_FLOAT or * I32_FLOAT, and the destination format for R32_FLOAT. On Sandy Bridge, |