[Piglit] [PATCH 1/8] layered-rendering/blit: use color other than the default red

[Pohjolainen, Topi]

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 <kenneth at whitecape.org>
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 <kenneth at whitecape.org>
    Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
    Tested-by: Martin Steigerwald <martin at lichtvoll.de>

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!
>