From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 3/4] drm/i915: Allow userspace to hint that the relocations were known Date: Sun, 11 Nov 2012 12:10:24 +0000 Message-ID: <453bf0$6e2rco@azsmga001.ch.intel.com> References: <1352560547-1423-1-git-send-email-chris@chris-wilson.co.uk> <1352560547-1423-3-git-send-email-chris@chris-wilson.co.uk> <20121110171616.GH5854@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by gabe.freedesktop.org (Postfix) with ESMTP id B6FDA9E78E for ; Sun, 11 Nov 2012 04:10:27 -0800 (PST) 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: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Sat, 10 Nov 2012 21:17:05 +0100, Daniel Vetter wrote: > Hm, I've thought we could get away for the gpu activity tracking by > unconditionally assuming that any passed-in object is in is in all > read domains. For cache flushing it doesn't matter what we set anyway > since we invalidate/flush unconditionally all caches before/after each > batch. And for activity tracking we unconditionally put all objects in > a given execbuf to the front of the active list (with updated > ring/seqno). The only important thing is to keep the write tracking to > not break our various read/read optimizations. One overlooked aspect is that the domain tracking helps with debugging and identifying what the buffers are used for. It has paid dividends many times when reading error-states, and certainly will prove to be useful again in future. -Chris -- Chris Wilson, Intel Open Source Technology Centre