drm/i915: Disable semaphores on Sandybridge
authorChris Wilson <chris@chris-wilson.co.uk>
Mon, 20 Nov 2017 20:55:02 +0000 (20:55 +0000)
committerChris Wilson <chris@chris-wilson.co.uk>
Mon, 20 Nov 2017 21:59:08 +0000 (21:59 +0000)
commit0da715ee60774401bea00dc71fca6fd1096c734a
treedb6641c5219b152b4daa2a7b49d628ea0135bd33
parent79e6770cb1f5e32eb49590edbb794a97d0113aed
drm/i915: Disable semaphores on Sandybridge

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]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54226 #and 100+ dupes
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171120205504.21892-3-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/i915_gem.c