On Fri, Nov 01, 2013 at 09:18:51AM -0700, Ben Widawsky wrote: > On Fri, Nov 01, 2013 at 05:08:17PM +0100, Daniel Vetter wrote: > > On Fri, Nov 01, 2013 at 12:53:42PM +0000, oscar.mateo@xxxxxxxxx wrote: > > > From: Oscar Mateo <oscar.mateo@xxxxxxxxx> > > > > > > We don't want a previously used object to be freed in the middle of a > > > before/after object counting operation (or we would get a "-1 objects > > > leaked" message). We have seen this happening, e.g., when a context > > > from a previous run dies, but its backing object is alive waiting for > > > a retire_work to kick in. > > > > > > Signed-off-by: Oscar Mateo <oscar.mateo@xxxxxxxxx> > > > Cc: Ben Widawsky <ben@xxxxxxxxxxxx> > > > > Nice catch. Should we do this in general as part of our gem_quiescent_gpu > > helper? All i-g-t testcase are written under the assumption that they > > completel own the gpu and that the gtt is completely empty besides the few > > driver-allocated and pinned objects. So trying really hard to get rid of > > any residual stuff sounds like a good idea. > > I was going to address this in the other mail thread.... in any case, I > think not. I believe a separate helper is the way to go, and we should > only call it when we absolutely want to. > > Though it's not the intention, I've seen many tests fail because of > previous state, and I don't want to miss out on those in the future. It > would also slow down the run unnecessarily further. We already do rather eregious stuff in quiescent. So I want hard numbers on your claim that it slows down stuff further - there really shouldn't be much at all to retire/evict. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
