Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
On Thu, Sep 11, 2014 at 12:53:30PM -0700, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk 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.vet...@ffwll.ch 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 ch...@chris-wilson.co.uk 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+ none2 2 2 1 1 gen2 X 16 16 32 16 32 gen3 X8 8 16 8 16 gen4+ X 8 8 16 8 8 gen2 Y 16 16 32 16 32 i915 Y8 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
Chris Wilson ch...@chris-wilson.co.uk writes: commit d21d781466785c317131a8a57606925867265dc8 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Feb 22 18:31:44 2011 +0100 Fix relaxed tiling on gen2 This one matches libdrm in using 16 for the tile height alignment on gen2. Try enabling relaxed fencing again. 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. If there's a stricter alignment requirement, then we must fix both the 2D driver and libdrm. Otherwise, the user's session will simply crash at startup. However, I still see absolutely no evidence that gen2 requires tile alignment to 32 rows, or that gen3+ requires tile alignment to 16 rows in any software configuration at all. -- keith.pack...@intel.com pgpB1HedFzRjW.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
Why doesn't mesa allocate buffers in the same way for those chips, then? Do you have any documentation about this? On Thu, Sep 11, 2014 at 12:37 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Sep 10, 2014 at 02:09:07PM -0700, Keith Packard wrote: [PATCH 2/2] Correct BO allocation alignment This patch makes UXA and Mesa agree about how buffers are allocated for images. Without this, UXA was requiring larger padding, which meant that converting some textures into pixmaps using DRI3 would fail. That extra alignment is due to gen2 and early gen3 (if (!intel-has_relaxed_fencing) covers them). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-de...@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Jasper ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
On Wednesday, September 10, 2014 02:09:07 PM Keith Packard wrote: Here are a couple of small bug fixes which make DRI3/Present work better with UXA. [PATCH 1/2] Do not clear pending kernel events on mode switch This patch prevents GL-based compositing managers from wedging when performing video mode setting. The problem was that DIX was never receiving notification about page flips being completed when one was pending across a mode switch. [PATCH 2/2] Correct BO allocation alignment This patch makes UXA and Mesa agree about how buffers are allocated for images. Without this, UXA was requiring larger padding, which meant that converting some textures into pixmaps using DRI3 would fail. -keith ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx Both are: Tested-by: Kenneth Graunke kenn...@whitecape.org I tested them using DRI3/Present + UXA and DRI3/Present + Glamor on Haswell GT3e. 1. Plug external 2560x1440 DisplayPort monitor into laptop. 2. echo 'exec startkde' ~/.xinitrc 3. startx 4. xrandr --output DP1 --auto This used to result in DP1 switching to 2560x1440, but KWin getting stuck waiting on a buffer idle event that never came, so you'd only see a 1920x1080 screen in the top left corner of the display, with either black or white bars in the other area. Other than the mouse cursor, nothing worked. With these patches, X works as expected. Thanks for the fixes, Keith! signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
On Wed, Sep 10, 2014 at 02:09:07PM -0700, Keith Packard wrote: [PATCH 2/2] Correct BO allocation alignment This patch makes UXA and Mesa agree about how buffers are allocated for images. Without this, UXA was requiring larger padding, which meant that converting some textures into pixmaps using DRI3 would fail. That extra alignment is due to gen2 and early gen3 (if (!intel-has_relaxed_fencing) covers them). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
On Thu, Sep 11, 2014 at 12:47:21AM -0600, Jasper St. Pierre wrote: Why doesn't mesa allocate buffers in the same way for those chips, then? Good question. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
Chris Wilson ch...@chris-wilson.co.uk 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: commit 736b89504a32239a0c7dfb5961c1b8292dd744bd Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sun Dec 30 10:32:18 2012 + uxa: Align surface allocations to even tile rows Align surface sizes to an even number of tile rows to cater for sampler prefetch. If we read beyond the last page we may catch the PTE in a state of flux and trigger a GPU hang. Also detected by enabling invalid PTE access checking. References: https://bugs.freedesktop.org/show_bug.cgi?id=56916 References: https://bugs.freedesktop.org/show_bug.cgi?id=55984 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Both of these bugs report regressions found past the 3.6 kernel, one on 965gm and the other on Ironlake. Are there additional bug reports on UXA which actually relate to this patch as it affects gen2 and gen3 hardware? Here's the patch that added the additional alignment restriction to SNA: commit 1b6c1a30723b1d13e9bd3df0b59a8d75639c89be Author: Chris Wilson ch...@chris-wilson.co.uk Date: Fri Nov 30 09:27:57 2012 + sna: Increase tiling alignment to an even tile Seems to help g4x. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Note that this does not reference gen2 or gen3 either. From the above two patches, all that I can learn is that both of these larger alignments were introduced to fix bugs on newer hardware, and that the larger alignment is now specifically disabled on that same hardware in the SNA code. Reading only this history, I felt reasonably confident that changing UXA back to what libdrm does was the best plan. 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. 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+ none2 2 2 1 1 gen2 X 16 16 32 16 32 gen3 X8 8 16 8 16 gen4+ X 8 8 16 8 8 gen2 Y 16 16 32 16 32 i915 Y8 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. 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. For pixmap allocations within the X server, we should ensure that the alignment requirements are at least as strict as those in libdrm so that pixmap passing from X to Mesa will work. Not that Mesa actually checks the provided buffer size at all, although it probably should.x It seems obvious to me that we should be doing this work in one place and sharing the code across the 2D and 3D drivers, and yet we never have. -- keith.pack...@intel.com pgpGkYFBBdj8Y.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA
Here are a couple of small bug fixes which make DRI3/Present work better with UXA. [PATCH 1/2] Do not clear pending kernel events on mode switch This patch prevents GL-based compositing managers from wedging when performing video mode setting. The problem was that DIX was never receiving notification about page flips being completed when one was pending across a mode switch. [PATCH 2/2] Correct BO allocation alignment This patch makes UXA and Mesa agree about how buffers are allocated for images. Without this, UXA was requiring larger padding, which meant that converting some textures into pixmaps using DRI3 would fail. -keith ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
