From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: Seperate fence pin counting from normal bind pin counting Date: Sat, 04 Jun 2011 19:31:27 +0100 Message-ID: References: <1307177743-3195-1-git-send-email-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 427929E7E9 for ; Sat, 4 Jun 2011 11:31:31 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Keith Packard , intel-gfx@lists.freedesktop.org Cc: Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org On Sat, 04 Jun 2011 10:38:07 -0700, Keith Packard wrote: > On Sat, 4 Jun 2011 09:55:43 +0100, Chris Wilson 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