[Intel-gfx] [PATCH] [RFC] drm/i915: read-read semaphore optimization

Eric Anholt eric at anholt.net
Wed Dec 14 02:09:45 CET 2011


On Tue, 13 Dec 2011 14:49:49 -0800, Ben Widawsky <ben at bwidawsk.net> wrote:
> On 12/13/2011 08:36 AM, Keith Packard wrote:
> > On Tue, 13 Dec 2011 17:01:33 +0100, Daniel Vetter <daniel at ffwll.ch> wrote:
> > 
> >> - or remove it all and invalidate/flush unconditionally.
> > 
> > Eric and I were chatting yesterday about trying this -- it seems like
> > we'd be able to dramatically simplify the kernel module by doing this,
> > and given how much flushing already occurs, I doubt we'd see any
> > significant performance difference, and we'd save a pile of CPU time,
> > which might actually improve performance.
> 
> 
> Would we want to keep domain tracking if the HW worked correctly and we
> didn't have to always flush. It seems like a shame to just gut the code
> if it actually could offer a benefit on future generations.

It's not a matter of hardware behavior.  It's a matter of always needing
to flush the caches anyway because you're emitting new commands at the
GPU and you're wanting results completed on the screen at the end.  So
we go to all this fragile, expensive CPU work to get no benefit.

We introduced this complexity with no evidence that it would help, just
because we thought, like you, that "avoiding cache flushes should be
good, right?".  Experiments so far say we were wrong.
-------------- 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/20111213/1f62eb32/attachment.sig>


More information about the Intel-gfx mailing list