On Sun, Jan 26, 2014 at 11:29:45PM -0800, Kenneth Graunke wrote: > On 01/26/2014 01:34 AM, Topi Pohjolainen wrote: > > Passes on nvidia and on IVB using blt-engine and mesa fallback > > path but fails on IVB using blorp (both before and after the > > recent refactoring): > > > > Probe color at (32,0) > > Expected: 0.500000 0.400000 0.300000 > > Observed: 0.250980 0.160784 0.090196 > > Probe color at (96,0) > > Expected: 0.500000 0.400000 0.300000 > > Observed: 0.250980 0.160784 0.090196 > > Probe color at (32,64) > > Expected: 0.500000 0.400000 0.300000 > > Observed: 0.250980 0.160784 0.090196 > > Probe color at (96,64) > > Expected: 0.500000 0.400000 0.300000 > > Observed: 0.250980 0.160784 0.090196 > > This looks a lot like botched SRGB handling. I saw BlitFramebuffers > with a source format of XRGB8888 and a destination format of SRGB8.
This is odd, I tried the latest mesa-master and for me the destination is either MESA_FORMAT_XRGB8888 (RGB-texture) or MESA_FORMAT_ARGB8888 (the framebuffer). > Commenting out the A -> 1.0 override in gen6_blorp_emit_blend_state > makes the test pass, so something's probably broken around there... As we discussed offline, I'll try a patch which effectively reverts: commit c0554141a9b831b4e614747104dcbbe0fe489b9d Author: Kenneth Graunke <[email protected]> Date: Mon Jan 28 22:03:18 2013 -0800 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. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Tested-by: Martin Steigerwald <[email protected]> diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp b/src/mesa/drivers/dri/i96 index eb61898..3834ae2 100644 --- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp +++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp @@ -283,6 +283,25 @@ gen6_blorp_emit_blend_state(struct brw_context *brw, blend->blend1.write_disable_b = false; blend->blend1.write_disable_a = false; + /* 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 (_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; } -- Our blorp logic samples the XRGB normally and gets alpha channel set to 1.0 automatically by the sampler engine. This is simply copied in the blorp blit program directly to the payload of the render target write message and hence we shouldn't need any additional blending support from the pixel processing pipeline. > > Good luck! > _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
