[igt-dev] [PATCH i-g-t] i915/gem_exec_nop: Add a light version of signal-all

[Chris Wilson]

Quoting Antonio Argenziano (2019-02-25 18:38:02)
> 
> 
> On 25/02/19 10:18, Chris Wilson wrote:
> > Quoting Ashutosh Dixit (2019-02-25 18:08:32)
> >> igt at gem-exec-nop@signal-all runs a single uninterrupted loop for 150
> >> sec. This results in the test being one of the longest execution times
> >> in CI runs. For example:
> >>
> >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5654/runtimes-iclb.txt
> >>
> >> Add a lighter version of the same test and include that in CI instead
> >> to cut down the overall CI execution time.
> >>
> >> Signed-off-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
> >> ---
> >>   tests/i915/gem_exec_nop.c    | 3 +++
> >>   tests/intel-ci/blacklist.txt | 2 +-
> >>   2 files changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/tests/i915/gem_exec_nop.c b/tests/i915/gem_exec_nop.c
> >> index 59a08ad0..87ecd6c7 100644
> >> --- a/tests/i915/gem_exec_nop.c
> >> +++ b/tests/i915/gem_exec_nop.c
> >> @@ -769,6 +769,9 @@ igt_main
> >>          igt_subtest("signal-all")
> >>                  fence_signal(device, handle, ALL_ENGINES, "all", 150);
> >>   
> >> +       igt_subtest("signal-all-light")
> >> +               fence_signal(device, handle, ALL_ENGINES, "all", 10);
> >> +
> >>          igt_subtest("series")
> >>                  series(device, handle, 150);
> >>   
> >> diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
> >> index f3440f31..166f158d 100644
> >> --- a/tests/intel-ci/blacklist.txt
> >> +++ b/tests/intel-ci/blacklist.txt
> >> @@ -34,7 +34,7 @@ igt at gem_exec_flush@(?!.*basic).*
> >>   igt at gem_exec_gttfill@(?!.*basic).*
> >>   igt at gem_exec_latency(@.*)?
> >>   igt at gem_exec_lut_handle(@.*)?
> >> -igt at gem_exec_nop@(?!.*(basic|signal-all)).*
> >> +igt at gem_exec_nop@(?!.*(basic|signal-all-light)).*
> > 
> > The real question is why is CI running it at all.
> Is there any value in running anything from gem_exec_nop?

Not a great deal. It's the minimal stress test. The signal subtest only
exists so that I could profile the cost of sending a dma_fence signal,
there's nothing along that path that makes me think there's concurrency
issues that need to beaten out.

As for the reset of gem_exec_nop, live_requests is meant to provide for
the trivial stress of hw, and this the uabi equivalent. The basic tests
here do have some interesting properties wrt to interengine
serialisation and is my glxgears of igt -- "does it even work?" And give
me a quick sanity check on whether anything is throwing off the cost of
request submission -- which is their real purpose.
-Chris