Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA

[Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>]

On Thu, Sep 11, 2014 at 12:53:30PM -0700, Keith Packard wrote:
> Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org> writes:
> 
> > That extra alignment is due to gen2 and early gen3 (if
> > (!intel->has_relaxed_fencing) covers them).
> 
> Here's the patch which changed the alignment requirment:

[snip commits picked at random]

This is the root

commit d21d781466785c317131a8a57606925867265dc8
Author: Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>
Date:   Tue Feb 22 18:31:44 2011 +0100

    Fix relaxed tiling on gen2

Later we went on to disable relaxed tiling even after believing we had
fixed all the kernel bugs:

commit 686018f283f1d131073ef5917213e6a8ac013f26
Author: Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Date:   Tue Apr 12 08:23:04 2011 +0100

    Turn relaxed-fencing off by default for older (pre-G33) chipsets
        
I believe the even-tile row alignment is still key to having gen2/gen3
function with relaxed fencing.

> If you have specific bug reports that were resolved by this patch, or
> specific hardware documentation which indicates that this patch is
> required, especially as it relates to gen2 and gen3 hardware, I'd love
> to see them.

Try enabling relaxed fencing again.
 
> In any case, we've now got four versions of the pixmap alignment code
> (libdrm, uxa and sna in two varieties). They're all subtly different;
> one suspects that each one works on some set of problems and fails on
> others...
> 
> Here's what the height alignment requirements are:
> 
>                 libdrm  uxa     uxa     sna     sna
>                       +keithp        >=2.6.38 <2.6.38
> 
> gen2 none         2      2       2       1       2
> gen3 none         2      2       2       1       2
> gen4+ none        2      2       2       1       1
> 
> gen2 X           16     16      32      16      32
> gen3 X            8      8      16       8      16
> gen4+ X           8      8      16       8       8
> 
> gen2 Y           16     16      32      16      32
> i915 Y            8     32      64       8      16
> i945 Y           32     32      64       8      16
> gen4+ Y          32     32      64      32      32
> 
> It looks like the SNA alignment for untiled buffers is incorrect? 965
> hardware is documented to read buffers in 2x2 chunks, so a failure to
> height align allocations to 2 can result in reads off the end of the
> buffer.

Reading from the scratch page is not a problem. Reading from
neighbouring surfaces is of no concern. The allocation must be suitable
and aligned appropriately for writes, but writes themselves are
appropriately clipped. Otherwise one extra row doesn't save you from
scribbling over anywhere in your gtt.
 
> For uxa's intel_set_pixmap_bo, and sna's sna_dri3_pixmap_from_fd,
> there's a clear requirement that the 2D driver impose no stricter
> alignment than libdrm, so that, buffer passing from Mesa to X will work.

No. The clearest requirement is that the ddx (or other display server)
must treat incoming surfaces as tainted and validate them to be sure
that they work with its code paths. If it can't we have a choice of
either rejecting them outright, or staging them.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel