From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA Date: Sat, 13 Sep 2014 09:28:24 +0100 Message-ID: <20140913082824.GM16043@nuc-i3427.alporthouse.com> References: <1410383349-27678-1-git-send-email-keithp@keithp.com> <20140911063716.GB28332@nuc-i3427.alporthouse.com> <86r3ziorwl.fsf@hiro.keithp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <86r3ziorwl.fsf-6d7jPg3SX/+z9DMzp4kqnw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: xorg-devel-bounces-go0+a7rfsptAfugRpC6u6w@public.gmane.org Sender: "xorg-devel" To: Keith Packard Cc: xorg-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org List-Id: intel-gfx@lists.freedesktop.org On Thu, Sep 11, 2014 at 12:53:30PM -0700, Keith Packard wrote: > Chris Wilson 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 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 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