On Sat, Jul 09, 2011 at 09:25:04AM +0100, Chris Wilson wrote: > In order to correctly account for reserving space in the GTT and fences > for a batch buffer, we need to independently track whether the fence is > pinned due to a fenced GPU access in the batch from from whether the > buffer is pinned in the aperture. Currently we count the fenced as > pinned if the buffer has already been seen in the execbuffer. This leads > to a false accounting of available fence registers, causing frequent > mass evictions. Worse, if coupled with the change to make > i915_gem_object_get_fence() report EDADLK upon fence starvation, the > batchbuffer can fail with only one fence required... > > Fixes intel-gpu-tools/tests/gem_fenced_exec_thrash > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38735 > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> > Tested-by: Paul Neumann <paul1...@yahoo.de>
I'm voting for an intel_unpin_fb_obj for symmetry (and so Jesse can't botch the sprite code) and maybe a paranoid WARN on if we put a pinned fence. But still Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
