summaryrefslogtreecommitdiffstats
path: root/src
diff options
context:
space:
mode:
authorKenneth Graunke <[email protected]>2016-08-02 11:04:01 -0700
committerKenneth Graunke <[email protected]>2016-08-08 14:01:51 -0700
commitcc27c7fe38dde3cfde30eb88dd5088b139d71f26 (patch)
treec8ea9b6108c6157d6368efb694cedc623282b5ef /src
parentb1586526e84ab6eab2023b589da8e153f70dda50 (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]>
Diffstat (limited to 'src')
-rw-r--r--src/mesa/drivers/dri/i965/brw_blorp_blit.cpp24
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, &params.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,