xf86-video-intel: src/i965_render.c

[Carl Worth]

 src/i965_render.c |   36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

New commits:
commit 76c9ece36e6400fd10f364ee330faea470e2da64
Author: Carl Worth <cworth at cworth.org>
Date:   Thu Oct 2 20:40:14 2008 -0700

    Fallback to software for RepeatNone with transformed RGB-only pictures.
    
    We wish it wouldn't, but the hardware ignores the alpha in the
    BorderColor we set when the source picture format has no alpha
    in it, (and it uses alpha of 1.0 where we want 0.0). For now,
    fallback for these cases. This gives a correct result, but
    obviously is not as fast as we would like.
    
    This fixes bug #16820:
    
    	[EXA] Composition result in black for areas outside of source-surface bounds
    	https://bugs.freedesktop.org/show_bug.cgi?id=16820

diff --git a/src/i965_render.c b/src/i965_render.c
index 2b59e91..709f3fd 100644
--- a/src/i965_render.c
+++ b/src/i965_render.c
@@ -254,6 +254,42 @@ i965_check_composite(int op, PicturePtr pSrcPicture, PicturePtr pMaskPicture,
     if (!i965_get_dest_format(pDstPicture, &tmp1))
 	I830FALLBACK("Get Color buffer format\n");
 
+    /* There's an infelicity of the 965 with respect to implementing
+     * RepeatNone for a source picture without alpha. The hardware's
+     * CLAMP_BORDER mode in this case doesn't match what Render, (and
+     * everyone, really), wants. Render expects that samples outside
+     * the bounds of the source picture will be transparent, but the
+     * hardware is documented as follows:
+     *
+     *     For surface formats with one or more channels missing, the
+     *     value from the border color is not used for the missing
+     *     channels, resulting in these channels resulting in the
+     *     overall default value (0 for colors and 1 for alpha)
+     *     regardless of whether border color is chosen.
+     *
+     *     [Intel 965 PRM; Volume 4; Section 4.7.4 SAMPLER_BORDER_COLOR_STATE]
+     *
+     * It's that hard-coding of "1 for alpha" that kills us.  Until we
+     * figure out a way to get the hardware to do what we want, we'll
+     * fall back to software. We fall back only if the operator uses
+     * the source alpha, the source format has no alpha, and there's
+     * a transform.
+     *
+     * For more complicated scenarios where there's a transform, but
+     * it won't actually result in any sampling outside the source
+     * picture, we'll have to rely on a higher layer,
+     * (ReduceCompositeOp in render/picture.c), that actually has
+     * access to the coordinates, to simplify the operator from Over
+     * to Source, for example.
+     */
+    if (i965_blend_op[op].src_alpha &&
+	(PICT_FORMAT_A(pSrcPicture->format) == 0) &&
+	pSrcPicture->transform)
+    {
+	I830FALLBACK("No support for alpha (RepeatNone) for an RGB-only picture\n");
+    }
+
+
     return TRUE;
 
 }