On 20/10/2016 15:02, Chris Wilson wrote:
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?

No sorry I read some later bits of the thread and came back to reply here - I was referring just to the igt codebase.

Regards,

Tvrtko


-Chris


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to