[Intel-gfx] [PATCH v3 3/3] intel-iommu: IOTLB hang workaround

From: David Woodhouse To work around a hardware issue, we have to submit IOTLB flushes while the graphics engine is idle. The graphics driver will go to great lengths to ensure that it gets that right on the affected chipset(s)... so let's not screw it over by deferring the unmap and doing it lat

[Intel-gfx] [PATCH v3 2/3] drm/i915: Fix hang on Ironlake mobile GPU with VT-d

Under certain circumstances, an IOTLB flush never completes and the hardware just locks up. The fix is meant to idle the GPU both before and after any unmap occurs, which should prevent the possibity to hang. Signed-off-by: Ben Widawsky --- drivers/char/agp/intel-gtt.c| 33 +++

[Intel-gfx] [PATCH v3 1/3] drm/i915: Remove early exit on i915_gpu_idle

[Description from: Daniel Vetter] I've just discussed this quickly with Chris on irc and it's probably best to just kill the list_empty early bailout. gpu_idle isn't a fastpath, so who cares. One candidate where we emit commands to the ring without adding anything onto these lists is e.g. pageflip.

[Intel-gfx] [PATCH v3 0/3] Ironlake mobile GPU with VT-d, fix

v1: (tested) idle GPU before and after unmaps. v2: (untested) Read GMCH_CTRL to find if VT-d is enable Pulled David's patch into the series Only stall for unmaps Add warning for list_empty && !rings_idle v3: (still untested) Removed warning stuff, got rid of early exit in i915_gpu_idle completely

[Intel-gfx] [PATCH v2 2/2] i965: Add calls to nonblocking maps

When mapping a range of a buffer that has the UNSYNCHRONIZED_BIT, and is only writable, we can take some shortcuts and let people shoot their feet. Cc: Eric Anholt Signed-off-by: Ben Widawsky --- src/mesa/drivers/dri/intel/intel_buffer_objects.c | 34 ++-- src/mesa/drivers/dri

[Intel-gfx] [PATCH v2 1/2] i965: Cleanup MapRangeBuffer

Clean the code up, and always use a BO when creating a new buffer. I've not seen any regressions but haven't yet tried this on < Gen6. Cc: Chad Versace Cc: Eric Anholt Signed-off-by: Ben Widawsky --- src/mesa/drivers/dri/intel/intel_buffer_objects.c | 114 ++--- src/mesa/drive

[Intel-gfx] [PATCH] spec: add on to Yuanhan's arb_map_buffer_range

Yuanhan recently added tests which check for conformance on the API. This patch goes on top of his to help make a dent in testing functionality. Cc: Yuanhan Liu Cc: Piglit Devs Signed-off-by: Ben Widawsky --- tests/all.tests|1 + tests/spec/arb_map_buffe

[Intel-gfx] [PATCH] intel: non-blocking mmaps on the cheap

From: Daniel Vetter This adds a new mode to map gem objects in a non-blocking way. The new kernel interface required to get the caching level/coherency is not yet wired up. All the code to transparently choose between gtt mappings or (if coherent) cpu mappings is already in place, though. To ma

[Intel-gfx] [PATCH v2] drm/i915: IOCTL to query the cache level of a BO.

Querying a BO's cache level can help clients wishing to map the buffer. For example, an Ironlake machine could query the buffer to determine it should use GTT mappings, while a Sandybridge machine running the same code would prefer to use regular CPU mapped buffers since the cache is coherent. Cc:

[Intel-gfx] [PATCH 0/5 v3] Nonblocking maps

After going back and forth many times, I think Daniel and I have agreed on the solution for non-blocking maps. This new interface adds a new call to map buffers non-blocking if possible. In actuality it may block, but it will track if the buffer needs flushing or not and does the right thing for t

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Ironlake mobile GPU with VT-d fix

On Sun, 25 Sep 2011 11:40:14 +0200 Daniel Vetter wrote: > On Sat, Sep 24, 2011 at 03:23:05PM -0700, Ben Widawsky wrote: > > Can you extract that horrible condition into e.g. > NEEDS_ILK_IOMMU_WORKAROUND or something like that? I think future me > will go wtf on this without the context ... >

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: add warning for unidle GPU

On Sun, 25 Sep 2011 12:16:36 +0200, Daniel Vetter wrote: > Also it looks like this causes us to no properly idle the gpu on > suspend/resume. Might fix issues especially on gen2/3 where we put an > MI_WAIT in front of the flip, hence enlarging the window to up to 20 ms. This I happen to disagree

Re: [Intel-gfx] [PATCH 0/4 v2] Nonblocking maps

On Fri, Sep 23, 2011 at 05:36:13PM -0700, Ben Widawsky wrote: > With the posted benchmark, there are significant improvements on Gen5 > with a very synthetic test meant to test unnecessary blocking on > architectures. The test is posted in the series for reference, but isn't > actually useful in it

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: add warning for unidle GPU

On Sat, Sep 24, 2011 at 03:23:04PM -0700, Ben Widawsky wrote: > When we attempt to idle the GPU we take a shortcut by checking if our > lists are empty and if so, avoid doing a synchronizing flush. The > warning will let us know if this assumption turns out to not be correct. > > Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Ironlake mobile GPU with VT-d fix

On Sat, Sep 24, 2011 at 03:23:05PM -0700, Ben Widawsky wrote: > Under certain circumstances, an IOTLB flush never completes and the hardware > just locks up. The fix is meant to idle the GPU both before and after > any unmap occurs. > > This patch also disables the warning which is meant to detec