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

[Chris Wilson <chris@chris-wilson.co.uk>]

On Sat, 04 Jun 2011 10:38:07 -0700, Keith Packard <keithp@keithp.com> wrote:
> On Sat,  4 Jun 2011 09:55:43 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 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?

The outline of the test case is (tuned for num_avail_fences):

batch 1 with 16 buffers, all with fenced relocations.
batch 2 with all 16 buffers from batch, but with no fenced relocations,
and 16 fresh buffers with fenced relocations.

At the start of batch 2, we first pin the 16 reused and currently bound
buffers from batch 1, which we do to avoid eviction any of those active
buffers to make room for batch 2. This has the side-effect of also
pinning all 16 fence registers, of which none are going to be used in
batch 2. Then when we try to pin and fence a fresh buffer, we cannot
find an available fence, abort the reservation and evict everything. On
the second pass we are then able to pin and fence, as required, all 32
buffers.

> 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.

Yes, we can't apply the EDEADLK patch until we fix the accounting.

> As this is a performance optimization, I also expect to see convincing
> benchmark data before this patch could be considered for merging.

Since the problem is that we prematurely run out of fences, we frequently
trigger evict_everything(inactive) and so cause mass evictions and clflush,
and a large performance regression for heavy fenced BLT usage:

Speedups on q35 (or equally because I finally noticed the regression of):
 midori-zoomed            3576.78 -> 2059.74: 1.74x speedup
 firefox-planet-gnome    14500.77 -> 9523.07: 1.52x speedup
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre