On Tue, Oct 18, 2016 at 01:48:52PM +0100, Chris Wilson wrote:
> On Tue, Oct 18, 2016 at 03:41:54PM +0300, Petri Latvala wrote:
> > How should vgem work be flushed properly? With this i915 flushing is
> > guaranteed even if vgem is opened first, then i915, but such
> > flushing won't be done if only
Late Tested-By: Jari Tahvanainen
I executed in HSW 100 times a test list having only one prime_vgem test case
and vgem_basic@unload.
With fix below: 100% pass for vgem_basic@unload
Without fix below: 100% skip for vgem_basic@unload
During last night I started 100 repetitions for fast-feedback
On Tue, Oct 18, 2016 at 01:48:52PM +0100, Chris Wilson wrote:
> vgem doesn't have the same delayed close as i915. For vgem, closing the
> fd (i.e. on process exit) will first signal all fences and drop
> references for that fd, so effectively all work will be completed. The
> external references to
On Tue, Oct 18, 2016 at 03:41:54PM +0300, Petri Latvala wrote:
> How should vgem work be flushed properly? With this i915 flushing is
> guaranteed even if vgem is opened first, then i915, but such
> flushing won't be done if only vgem is opened (I see only vgem_slow
> doing that)...
vgem doesn't h
On 10/18/2016 02:36 PM, Chris Wilson wrote:
On Tue, Oct 18, 2016 at 02:25:21PM +0300, Petri Latvala wrote:
If executed too soon after prime_vgem tests, the vgem unload test
fails due to its execbuffers still being handled in the kernel. Retry
the unload three times with sleeps before reporting
On Tue, Oct 18, 2016 at 02:25:21PM +0300, Petri Latvala wrote:
> If executed too soon after prime_vgem tests, the vgem unload test
> fails due to its execbuffers still being handled in the kernel. Retry
> the unload three times with sleeps before reporting a skip.
What happened to igt ensuring tha