Re: [PATCH 1/3] drm/i915: Disable sempahores on Sandybridge

[Chris Wilson <chris@chris-wilson.co.uk>]

Quoting Chris Wilson (2017-10-28 12:27:23)
> I should have admitted defeat long ago as there has been a rare but
> persistent error on Sandybridge where semaphore signaling did not
> propagate to the waiter, leading to a GPU hang.
> 
> With the work on fence signaling for v4.9, the impact of using CPU driven
> signaling was greatly reduced wrt to the latency of GPU semaphores,
> though without logical rings support, the benefit of reordering work to
> avoid bubbles is not realised (i.e. as it stands fence signaling is just
> a slower, more costly version of HW semaphores; but works more
> consistently). As a rough indicator of the difference,
> 
> with semaphores:
> Sequential (3 engines, 1 processes): average 5.470us per cycle [expected 4.988us]
> 
> w/o semaphores:
> Sequential (3 engines, 1 processes): average 15.771us per cycle [expected 4.923us]

In comparison, v3.4:

with semaphores:
Sequential (3 engines, 1 processes): average 16.066us per cycle [expected 11.842us]

w/o semaphores:
Sequential (3 engines, 1 processes): average 23.460us per cycle [expected 11.839us]

Interesting in that this microbenchmark doesn't show as big as an impact
that drove adoption of semaphores (originally it gave ~3x better
performance for x11perf), and that know even without semaphores we are
faster than a few years ago. Further, since the split engines in
Sandybridge userspace has learnt not to frequently jump between engines.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx