On Sat,  4 Jun 2011 09:55:43 +0100, Chris Wilson <chris@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.packard@intel.com