On Sat, 4 Jun 2011 09:55:43 +0100, Chris Wilson <ch...@chris-wilson.co.uk> 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... I'm afraid you've completely lost me here. Can you provide a small example (libdrm?) program which exhibits the failure so I can follow what the problem is? And, if I understand any of this at all, I should remove the patch to return -EDEADLK from i915_gem_object_get_fence as we may run out of fence registers even if the client is accounting for them correctly. If so, I'll remove that from my list of -fixes patches. As this is a performance optimization, I also expect to see convincing benchmark data before this patch could be considered for merging. -- keith.pack...@intel.com
pgpgtnxP0F9iW.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
