Re: [PATCH] drm/i915: Seperate fence pin counting from normal bind pin counting

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1319 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx