]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit4574a7b048a705b3db73f923f938fe01a52037fc
treedb6641c5219b152b4daa2a7b49d628ea0135bd33
parent427f3b1da322547c76b0a52874b47fc9b360a388
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