[Intel-gfx] [PATCH] drm/i915: Update write_domains on active list after flush.

[Eric Anholt]

On Sun, 7 Feb 2010 18:39:49 +0100, Adam Lantos <hege at playma.org> wrote:
> On Sun, Feb 7, 2010 at 4:20 PM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> > Before changing the status of a buffer with a pending write we will await
> > upon a new flush for that buffer. So we can take advantage of any flushes
> > posted whilst the buffer is active and pending processing by the GPU, by
> > clearing its write_domain and updating its last_rendering_seqno -- thus
> > saving a potential flush in deep queues and improves flushing behaviour
> > upon eviction for both GTT space and fences.
> >
> > In order to reduce the time spent searching the active list for matching
> > write_domains, we move those to a separate list whose elements are
> > the buffers belong to the active/flushing list with pending writes.
> >
> > Orignal patch by Chris Wilson <chris at chris-wilson.co.uk>, forward-ported
> > by me.
> >
> > In addition to better performance, this also fixes a real bug. Before
> > this changes, i915_gem_evict_everything didn't work as advertised. When
> > the gpu was actually busy and processing request, the flush and subsequent
> > wait would not move active and dirty buffers to the inactive list, but
> > just to the flushing list. Which triggered the BUG_ON at the end of this
> > function. With the more tight dirty buffer tracking, all currently busy and
> > dirty buffers get moved to the inactive list by one i915_gem_flush operation.
> >
> > I've left the BUG_ON I've used to prove this in there.
> >
> > References:
> >  Bug 25911 - 2.10.0 causes kernel oops and system hangs
> >  http://bugs.freedesktop.org/show_bug.cgi?id=25911
> >
> >  Bug 26101 - [i915] xf86-video-intel 2.10.0 (and git) triggers kernel oops
> >              within seconds after login
> >  http://bugs.freedesktop.org/show_bug.cgi?id=26101
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> > ---
> >
> > Same patch rebased to apply to .32-stable (and linus mainlin, too).
> > Compile-tested only.
> 
> This patch seems to fix the BUG_ON in my case. However, I still have
> lots of these:
> 
> [drm:i915_gem_object_pin_and_relocate] *ERROR* Failure to install fence: -28
> [drm:i915_gem_object_pin_and_relocate] *ERROR* Failure to install fence: -28
> [drm:i915_gem_do_execbuffer] *ERROR* Failed to pin buffer 5 of 7,
> total 8519680 bytes: -28
> [drm:i915_gem_do_execbuffer] *ERROR* 369 objects [7 pinned], 91172864
> object bytes [11747328 pinned], 11780096/260308992 gtt bytes

This commit ought to fix those:

commit fdcde592c2c48e143251672cf2e82debb07606bd
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Tue Feb 9 08:32:54 2010 +0000

    intel: Account for potential pinned buffers hogging fences

(Having the kernel tell the current value wouldn't help in this case,
since the current value can change periodically and we don't actually
want to keep asking the kernel what current is just in case we can have
one extra fence reg).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100210/8638fc23/attachment.sig>