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 vgem is opened (I see only vgem_slow > > doing that)... > > 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 the vgem.ko's object (via dma-buf) will only > exist if they were constructed by the test and if they were, e.g. i915, > they too should be will be flushed by igt in its exithandlers. > > Other drivers may have similar bridges to cross ofc. One long-term caveat is that exit handlers only run on final exit, not after each subtest. Atm that's no issue because we run each subtest in isolation. But I think that for throughput reasons (some of the testcases run _much_ faster if you just launch the binary once, due to fairly heavy overhead in igt_fixtures) we can't rely on that forever. Mostly thinking of high-throughput complete test runs here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
