On Fri, Jan 15, 2016 at 02:45:49PM +0000, Tvrtko Ursulin wrote:
>
> On 15/01/16 13:53, Chris Wilson wrote:
> >Exercise the busy-ioctl and verify it reports the right active engines
> >using the execbuffer notation.
> >
> >Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> >---
> > tests/Makefile.sources | 1 +
> > tests/gem_busy.c | 233 +++++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 234 insertions(+)
> > create mode 100644 tests/gem_busy.c
> >
> >diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> >index d2c7d6f..545aca0 100644
> >--- a/tests/Makefile.sources
> >+++ b/tests/Makefile.sources
> >@@ -11,6 +11,7 @@ TESTS_progs_M = \
> > drv_hangman \
> > gem_bad_reloc \
> > gem_basic \
> >+ gem_busy \
> > gem_caching \
> > gem_close_race \
> > gem_concurrent_blit \
> >diff --git a/tests/gem_busy.c b/tests/gem_busy.c
> >new file mode 100644
> >index 0000000..c6b8a8b
> >--- /dev/null
> >+++ b/tests/gem_busy.c
> >@@ -0,0 +1,233 @@
> >+/*
> >+ * Copyright © 2015 Intel Corporation
>
> 2016
Already?
> >+ __gem_busy(fd, object[0].handle, &read, &write);
> >+ igt_assert_eq(read, 1 << write);
> >+ igt_assert_eq(write, gen >= 6 ? I915_EXEC_BLT : I915_EXEC_RENDER);
>
> Will the blits be long enough for this to be stable?
I can bump it by a factor of 5 easily enough, that should put it in the
range of a few milliseconds even on a fast system. If we get rescheduled,
we might miss the window for the test.
I did think of asserting that the blit was still busy eash time.
> >+ /* Queue a batch after the busy, it should block and remain "busy" */
> >+ igt_require(exec_noop(fd, handle, ring | flags, false));
>
> Too bad we don't get ENODEV but a boring old EINVAL on !HAS_BSD2 -
> this was this can be too skip happy if something else gets broken.
> :(
True, but it would be better to have a test that checked which rings the
kernel said were on the hardware and that execbuffer supported them.
> >+igt_main
> >+{
> >+ int fd = -1;
> >+
> >+ igt_skip_on_simulation();
> >+
> >+ igt_fixture {
> >+ fd = drm_open_driver(DRIVER_INTEL);
> >+ igt_require(has_semaphores(fd));
>
> Copy&paste, or?
A requirement. At least on the current infrastructure. It uses the sync
with the write on the BLT ring to block the GPU on the other rings, so
that the nops don't complete too early. We would need a busy workload on
each engine - code that we don't have yet.
Without semaphores, and without deferred scheduling, we current wait for
the busy workload to complete before scheduling on the next...
If I lie about the busywork being a write target, we will get parallel
execution rather than blocking and so not be able to set the right
flags. I couldn't see a way around semaphores without gen specific new
code.
> Maybe mark as basic since it is ABI?
Can't until the kernel abides by the abi we just concocted :) I
definitely don't trust my judgement as to what is basic. Surviving weeks
of stress testing is a basic requirement for us :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
