https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2163/shard-hsw1/igt@gem_busy@extended-semaphore-blt.html Starting subtest: extended-semaphore-blt (gem_busy:11036) CRITICAL: Test assertion failure function semaphore, file ../tests/i915/gem_busy.c:143: (gem_busy:11036) CRITICAL: Failed assertion: read == active (gem_busy:11036) CRITICAL: error: 26 != 30 Subtest extended-semaphore-blt failed. https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_174/fi-byt-n2820/igt@gem_busy@extended-semaphore-blt.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_174/fi-byt-j1900/igt@gem_busy@extended-semaphore-blt.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_174/fi-byt-clapper/igt@gem_busy@extended-semaphore-blt.html Starting subtest: extended-semaphore-blt (gem_busy:3014) CRITICAL: Test assertion failure function semaphore, file ../tests/i915/gem_busy.c:143: (gem_busy:3014) CRITICAL: Failed assertion: read == active (gem_busy:3014) CRITICAL: error: 10 != 14 Subtest extended-semaphore-blt failed.
Something fishy with semaphores maybe? As we also have the gem_exec_fence failures only on the semaphore driver hsw. The future looks bleak for continuing to use semaphores, at which point this test becomes defunct and the issue evaporates.
Tests are defunct since commit 6faf5916e6beb0dedb0fcbbafbaa152adeaea758 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Dec 28 14:07:35 2018 +0000 drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation The writing is on the wall for the existence of a single execution queue along each engine, and as a consequence we will not be able to track dependencies along the HW queue itself, i.e. we will not be able to use HW semaphores on gen7 as they use a global set of registers (and unlike gen8+ we can not effectively target memory to keep per-context seqno and dependencies). On the positive side, when we implement request reordering for gen7 we also can not presume a simple execution queue and would also require removing the current semaphore generation code. So this bring us another step closer to request reordering for ringbuffer submission! The negative side is that using interrupts to drive inter-engine synchronisation is much slower (4us -> 15us to do a nop on each of the 3 engines on ivb). This is much better than it was at the time of introducing the HW semaphores and equally important userspace weaned itself off intermixing dependent BLT/RENDER operations (the prime culprit was glyph rendering in UXA). So while we regress the microbenchmarks, it should not impact the user. References: https://bugs.freedesktop.org/show_bug.cgi?id=108888 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181228140736.32606-2-chris@chris-wilson.co.uk
(In reply to Chris Wilson from comment #2) > Tests are defunct since > > commit 6faf5916e6beb0dedb0fcbbafbaa152adeaea758 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Fri Dec 28 14:07:35 2018 +0000 > > drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation > > The writing is on the wall for the existence of a single execution queue > along each engine, and as a consequence we will not be able to track > dependencies along the HW queue itself, i.e. we will not be able to use > HW semaphores on gen7 as they use a global set of registers (and unlike > gen8+ we can not effectively target memory to keep per-context seqno and > dependencies). > > On the positive side, when we implement request reordering for gen7 we > also can not presume a simple execution queue and would also require > removing the current semaphore generation code. So this bring us another > step closer to request reordering for ringbuffer submission! > > The negative side is that using interrupts to drive inter-engine > synchronisation is much slower (4us -> 15us to do a nop on each of the 3 > engines on ivb). This is much better than it was at the time of > introducing > the HW semaphores and equally important userspace weaned itself off > intermixing dependent BLT/RENDER operations (the prime culprit was glyph > rendering in UXA). So while we regress the microbenchmarks, it should not > impact the user. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108888 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> > Link: > https://patchwork.freedesktop.org/patch/msgid/20181228140736.32606-2- > chris@chris-wilson.co.uk Thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.