[Intel-gfx] [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity

[Chris Wilson]

On Thu, Mar 03, 2016 at 03:43:49PM +0000, Tvrtko Ursulin wrote:
> 
> On 03/03/16 15:11, Chris Wilson wrote:
> >On Thu, Mar 03, 2016 at 02:36:44PM +0000, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>
> >>Currently the wait_for_atomic_us only allows for a millisecond
> >>granularity which is not nice towards callers requesting small
> >>micro-second waits.
> >
> >Hmm, by granularity I think of the interval between COND reads. That
> >should be the limiting factor in how fast we respond to the change in
> >event (and so for the atomic variants should be virtually the same).
> 
> Yeah not that granularity, should I say "timeout granularity" then
> in the commit? Before if someone wanted to wait for, say 10us, it
> would have busy looped for one jiffie instead. In the timeout
> scenario that is. That is the headline improvement.

"timeout granularity" would be much clearer

> >Your suggestion that it is icache or similar is probably along the right
> >path. A quick code size measurement of a test function would be a good
> >supporting argument.
> 
> I am not sure. It shaves ~3.3% (12 of original 353 bytes) of the
> whole fw_domains_get which even if it is quite hot as you know, and
> even 3% from the main loop in wait for atomic (3% here is a glorious
> one byte). So I am not sure, but gem_latency results were quite
> convincing. Unexplained for me.

Ok. The small improvement in addition to stronger compile-time checks is
certainly enough justification. The motivation is usually to avoid
hitting the wait_for(register) loop in the first place, and a good
mystery is always a good read for a rainy day.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre