summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTopi Pohjolainen <topi.pohjolainen@intel.com>2014-01-27 10:50:01 +0200
committerCarl Worth <cworth@cworth.org>2014-03-04 13:00:47 -0800
commit2a1918695373a8306deac2a55d6f10492ceb775a (patch)
treee9ca94d009b60f9a449fab92f374779d89353705
parentdc0053b33f5bd95965c1820d814edc2ab6d8b5c9 (diff)
downloadmesa-2a1918695373a8306deac2a55d6f10492ceb775a.tar.gz
i965/blorp: do not use unnecessary hw-blending support
This is really not needed as blorp blit programs already sample XRGB normally and get alpha channel set to 1.0 automatically by the sampler engine. This is simply copied directly to the payload of the render target write message and hence there is no need for any additional blending support from the pixel processing pipeline. The blending formula is anyway broken for color components, it multiplies the color component with itself (blend factor is the component itself). Alpha blending in turn would not fix the alpha to one independent of the source but simply used the source alpha as is instead (1.0 * src_alpha + 0.0 * dst_alpha). Quoting Eric: "If we want to actually make the no-alpha-bits-present thing work, we need to override the bits in the surface state or in the generated code. In the normal draw path, it's done for sampling by the swizzling code in brw_wm_surface_state.c, and the blending overrides is just to fix up the alpha blending stage which doesn't pay attention to that for the destination surface." If one modifies piglit test gl-3.2-layered-rendering-blit to use color component values other than zero or one, this change will kick in on IVB. No regressions on IVB. This is effectively revert of c0554141a9b831b4e614747104dcbbe0fe489b9d: i965/blorp: Support overriding destination alpha to 1.0. Currently, Blorp requires the source and destination formats to be equal. However, we'd really like to be able to blit between XRGB and ARGB formats; our BLT engine paths have supported this for a long time. For ARGB -> XRGB, nothing needs to occur: the missing alpha is already interpreted as 1.0. For XRGB -> ARGB, we need to smash the alpha channel to 1.0 when writing the destination colors. This is fairly straightforward with blending. For now, this code is never used, as the source and destination formats still must be equal. The next patch will relax that restriction. NOTE: This is a candidate for the 9.1 branch. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com> (cherry picked from commit 933be19cdf97aed977cd656e5c15c99cbdb52b7f)
-rw-r--r--src/mesa/drivers/dri/i965/gen6_blorp.cpp20
1 files changed, 0 insertions, 20 deletions
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index a132234e1fa..1f47f95451c 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -254,26 +254,6 @@ gen6_blorp_emit_blend_state(struct brw_context *brw,
blend->blend1.write_disable_b = params->color_write_disable[2];
blend->blend1.write_disable_a = params->color_write_disable[3];
- /* When blitting from an XRGB source to a ARGB destination, we need to
- * interpret the missing channel as 1.0. Blending can do that for us:
- * we simply use the RGB values from the fragment shader ("source RGB"),
- * but smash the alpha channel to 1.
- */
- if (params->src.mt &&
- _mesa_get_format_bits(params->dst.mt->format, GL_ALPHA_BITS) > 0 &&
- _mesa_get_format_bits(params->src.mt->format, GL_ALPHA_BITS) == 0) {
- blend->blend0.blend_enable = 1;
- blend->blend0.ia_blend_enable = 1;
-
- blend->blend0.blend_func = BRW_BLENDFUNCTION_ADD;
- blend->blend0.ia_blend_func = BRW_BLENDFUNCTION_ADD;
-
- blend->blend0.source_blend_factor = BRW_BLENDFACTOR_SRC_COLOR;
- blend->blend0.dest_blend_factor = BRW_BLENDFACTOR_ZERO;
- blend->blend0.ia_source_blend_factor = BRW_BLENDFACTOR_ONE;
- blend->blend0.ia_dest_blend_factor = BRW_BLENDFACTOR_ZERO;
- }
-
return cc_blend_state_offset;
}