From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] [RFC] drm/i915: read-read semaphore optimization Date: Tue, 13 Dec 2011 09:49:34 +0000 Message-ID: References: <1323748328-10153-1-git-send-email-ben@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 7C9D79E7E7 for ; Tue, 13 Dec 2011 01:49:56 -0800 (PST) In-Reply-To: <1323748328-10153-1-git-send-email-ben@bwidawsk.net> 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: intel-gfx@lists.freedesktop.org Cc: Daniel Vetter , Ben Widawsky List-Id: intel-gfx@lists.freedesktop.org On Mon, 12 Dec 2011 19:52:08 -0800, Ben Widawsky wrote: > Since we don't differentiate on the different GPU read domains, it > should be safe to allow back to back reads to occur without issuing a > wait (or flush in the non-semaphore case). > > This has the unfortunate side effect that we need to keep track of all > the outstanding buffer reads so that we can synchronize on a write, to > another ring (since we don't know which read finishes first). In other > words, the code is quite simple for two rings, but gets more tricky for > > 2 rings. > > Here is a picture of the solution to the above problem > > Ring 0 Ring 1 Ring 2 > batch 0 batch 1 batch 2 > read buffer A read buffer A wait batch 0 > wait batch 1 > write buffer A > > This code is really untested. I'm hoping for some feedback if this is > worth cleaning up, and testing more thoroughly. Yes, that race is quite valid and the reason why I thought I hadn't made that optimisation. Darn. :( To go a step further, we can split the obj->ring_list into (obj->ring_read_list[NUM_RINGS], obj->num_readers, obj->last_read_seqno) and (obj->ring_write_list, obj->last_write_seqno). At which point Daniel complains about bloating every i915_gem_object, and we probably should kmem_cache_alloc a i915_gem_object_seqno on demand. This allows us to track objects in multiple rings and implement read-write locking, albeit at significantly more complexity in managing the active lists. -Chris -- Chris Wilson, Intel Open Source Technology Centre