[igt-dev] [PATCH][PATCH i-g-t] tests/i915/gem_write_read_ring_switch Removal of IGT Test

[Nedunoori, Sravan Kumar]

>Given that outline, could we whip up a new pair of tests (implicit-read-fence, implicit-write-fence) for gem_exec_schedule?
[Sravan] : Sure, will enhance the gem_exec_schedule with the Implicit-read/write-fence subtests. 

Can we go ahead with the change/patch(gem_write_read_ring_switch) 

-Sravan Kumar Nedunoori 

-----Original Message-----
From: Chris Wilson <chris at chris-wilson.co.uk> 
Sent: Friday, February 14, 2020 4:35 AM
To: igt-dev at lists.freedesktop.org; Nedunoori, Sravan Kumar <sravan.kumar.nedunoori at intel.com>
Subject: Re: [igt-dev] [PATCH][PATCH i-g-t] tests/i915/gem_write_read_ring_switch Removal of IGT Test

Quoting Sravan Kumar Nedunoori (2020-02-13 04:50:04)
> Removal of this test, as it checks read/write syncpoints when 
> switching rings and doesn't add anything to other tests.

write/read sync. Ah, I was thinking about read/read and the only thing that came to mind as proving that would be the gem_busy/extended

Ok, this is covered by the gem_exec_whisper brute, but do we have a simple and clear test to show that writes are blocked by a reader?

for_each_physical_engine(writer)
	dep = gem_create(4096);
	for_each_physical_engine(reader) {
		if (reader == write)
			continue;
		/* XXX with a few tweaks write a secret breadcrumb */
		igt_spin_new(reader, .read = dep);
	}
	breadcrumb(write, dep); /* implicit fence -> queued after readers */
	gem_quiescent_gpu(); /* cancels all spinners */
	igt_assert_eq(breadcrumb == writers);
}
/* This can be reversed to test write->reader implicit fences */

that feels very, very much like a test we have somewhere. But I couldn't put my finger on which one.

Given that outline, could we whip up a new pair of tests (implicit-read-fence, implicit-write-fence) for gem_exec_schedule?

-Chris