drm/i915: disable flushing_list/gpu_write_list
commitcc889e0f6ce6a63c62db17d702ecfed86d58083f
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Wed, 13 Jun 2012 18:45:19 +0000 (13 20:45 +0200)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Wed, 20 Jun 2012 11:54:28 +0000 (20 13:54 +0200)
treea3e1154ba534b842ca428ea257f27290ece81e7b
parent8e88a2bd5987178d16d53686197404e149e996d9
drm/i915: disable flushing_list/gpu_write_list

This is just the minimal patch to disable all this code so that we can
do decent amounts of QA before we rip it all out.

The complicating thing is that we need to flush the gpu caches after
the batchbuffer is emitted. Which is past the point of no return where
execbuffer can't fail any more (otherwise we risk submitting the same
batch multiple times).

Hence we need to add a flag to track whether any caches associated
with that ring are dirty. And emit the flush in add_request if that's
the case.

Note that this has a quite a few behaviour changes:
- Caches get flushed/invalidated unconditionally.
- Invalidation now happens after potential inter-ring sync.

I've bantered around a bit with Chris on irc whether this fixes
anything, and it might or might not. The only thing clear is that with
these changes it's much easier to reason about correctness.

Also rip out a lone get_next_request_seqno in the execbuffer
retire_commands function. I've dug around and I couldn't figure out
why that is still there, with the outstanding lazy request stuff it
shouldn't be necessary.

v2: Chris Wilson complained that I also invalidate the read caches
when flushing after a batchbuffer. Now optimized.

v3: Added some comments to explain the new flushing behaviour.

Cc: Eric Anholt <eric@anholt.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem_execbuffer.c
drivers/gpu/drm/i915/intel_ringbuffer.h