From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 3/6] drm/i915: Remove the per-ring write list Date: Fri, 13 Jul 2012 10:34:43 +0200 Message-ID: <20120713083426.GA5721@phenom.ffwll.local> References: <1342106019-17806-1-git-send-email-chris@chris-wilson.co.uk> <1342106019-17806-4-git-send-email-chris@chris-wilson.co.uk> <20120712193716.GN5039@phenom.ffwll.local> <1342123681_2236@CP5-2952> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id 0E5C69E789 for ; Fri, 13 Jul 2012 01:34:45 -0700 (PDT) Received: by wgbdr1 with SMTP id dr1so2467645wgb.12 for ; Fri, 13 Jul 2012 01:34:45 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1342123681_2236@CP5-2952> 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: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Thu, Jul 12, 2012 at 09:07:52PM +0100, Chris Wilson wrote: > On Thu, 12 Jul 2012 21:37:16 +0200, Daniel Vetter wrote: > > On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote: > > > obj->base.write_domain = 0; > > > - list_del_init(&obj->gpu_write_list); > > > + obj->pending_gpu_write = false; > > > i915_gem_object_move_to_inactive(obj); > > > > Hm, this hunk makes me wonder whether we don't leak some bogus state > > accross a gpu reset. Can't we just reuse the move_to_inactive helper here, > > ensuring that we consistenly clear up any active state? > > Yes. I had planned to finish off with another patch to remove that pair > of then redundant lines, but apparently forgot. I think it is better > expressed as a second patch, at least from the point of view of how I > was applying the transformations. Actually I've been confused yesterday, we do call move_to_inactive in the next line ;-) I've looked again at your patch, and the changes to how we handle obj->pending_pug_write look buggy. The above hunk is superflous, because move_to_inactive will do that. The hunk int i915_gem_execbuffer's is buggy, we can't clear pending_gpu_write there - we use that to decide whether we need to stall for the gpu when the cpu does a read-only accesss. We then stall completely because we don't keep track of the last write seqno separately. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48