On Fri, Feb 13, 2015 at 10:03:49AM +0100, Daniel Vetter wrote: > On Thu, Feb 12, 2015 at 09:48:23AM +0000, Chris Wilson wrote: > > On Thu, Feb 12, 2015 at 10:43:44AM +0100, Daniel Vetter wrote: > > > On Thu, Feb 12, 2015 at 07:53:18AM +0000, Chris Wilson wrote: > We still need to grab dev->struct_mutex of course to avoid seeing bo > pinned for execbuf. Just thought we could avoid the list walk in > set_tiling as a super-micro-opt. When we have an igt that combines thousands of vm with set-tiling, then we might notice! :) > > > Either way this is > > > > > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > Cc: stable@xxxxxxxxxxxxxxx (we have some vague evidence that it blows up > > > at last) > > > > > > I've also audited all the other callers of is_pinned, the only other > > > suspicious one is the one in capture_bo. Perhaps we should also move that > > > over to obj->framebuffer_references? > > > > We killed that over a year ago in the conversion of error capture over > > to vma for full-ppgtt prepartion... Right? > > No, that was left semantically unchanged in the switch. So I guess we > should dump vma->pin_count and obj->framebuffer_references? I meant we sent patches to improve error states for full-ppgtt. vma->pin_count is not interesting, since that is only done for execbuf, I only care about the GTT pinned objects since they are what we have pinned on behalf of hardware (and so are useful for crosschecking against register state), and that is what we specifically dump. Adding obj->framebuffer_references would be interesting, as well as the list of current framebuffers i.e. i915_gem_framebuffers. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
