On Thu, Dec 4, 2014 at 12:29 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
