On Thu, Oct 20, 2016 at 02:55:42PM +0100, Tvrtko Ursulin wrote:
>
> On 20/10/2016 10:16, Daniel Vetter wrote:
> >On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote:
> >>On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote:
> >>>On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote:
> >>>>The inter-engine synchronisation (with and without semaphores) is
> >>>>equally exercised by gem_sync, so leave gem_storedw_loop out of the
> >>>>"quick" set.
> >>>
> >>>How equally is "equally"? Is the test actually redundant, should it be
> >>>removed altogether?
> >>The stress patterns exhibited by the test are identical to others in
> >>BAT. The accuracy tests are covered by others in BAT. The actual flow
> >>(edge coverage) will be subtly different and therefore the test is still
> >>unique and may catch future bugs not caught by others. But as far as BAT
> >>goes the likelihood of this catching something not caught by others
> >>within BAT is very very small.
> >But given that we have 50k gem tests in full igt, does it really make
> >sense to keep it? Imo there's not much point in keeping around every
> >minute combinatorial variation if it means we can never run the full set
> >of testcases. Some serious trimming of the herd is probably called for.
> >
> >Joonas/Tvrtko/Mika and other gem folks: What's your stance here?
>
> I am very fond of gem_storedw_loop, it was indispensable during
> platform bringup in Fulsim in a not so distant past.
>
> Even if not so, it is a very short and simple test ("Basic CS check
> using MI_STORE_DATA_IMM"), while gem_sync is much more complex and
> deals with a different issues.
See gem_exec_store for an even shorter sanity test of CS (also in BAT).
We have overlap between this, gem_exec_basic, gem_exec_store,
gem_exec_nop, gem_ringfill and gem_sync.
> Without going into wider discussion, I vote to keep this particular test.
In BAT?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
