[Intel-gfx] [PATCH 3/3] drm/i915: add fences to the request struct

[Daniel Vetter]

On Thu, Dec 4, 2014 at 12:29 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> It uses locked atomic operations, which are unnecessary for the very
> frequent is-complete checks (due to the nice ordering constraints of x86).

So let's look at the fastpaths:
- fence already signaled: Just a test_bit which amounts to a normal read on x86.
- fence not yet signaled: Just a call into the driver backend.
Obviously we want to keep the lazy coherency trick for i915, but
struct fence already has the concept of lazy coherency: By default
they only signal "somewhen", you need to call ->enable_signalling for
tight guarantees. We can just reuse the book-keeping bit struct fence
already has to compute lazy_coherency. So no additional atomics
compared to our current fastpath.
- signalling a fence: This one indeed did grow a test_and_set_bit, so
a regression in the fastpath (locks will only be taking when the fence
is already in the accurate slowpath mode). But this is only once per
fence so hopefully doesn't hurt. If it does we can fix it by trading
speed for memory and putting the signalling bit into it's own word,
resulting in a simple store.

So looks all good or fixable. The only real issue is that the slowpath
cost is beared by all threads if just one thread goes into a slowpath.
So a notch less fair for this case. But in the normal case where
everyone just checks business to manage caches this shouldn't happen.

Or did I miss something? In that case we should really try to fix
fences first, since they're meant to be fast in the fastpaths at least
and used universally.

> You have me confused. You keep applying patches without solid data to
> back up your claims.

I guess you mean the ggtt vma first, which imo really just reverts
premature optimization. But the point of the separate patch (and me
merging it quickly) is to catch regressions and issues. So if we
really need this I'll happily revert the patch (so that we can add the
perf data the first attempt lacked and store it for perpetuity).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch