Re: [PATCH] drm/i915: optimize the shmem_pwrite slowpath handling

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm/i915: optimize the shmem_pwrite slowpath handling
Date: Thu, 15 Nov 2012 15:37:01 +0000	[thread overview]
Message-ID: <453bf0$6g3v6k@azsmga001.ch.intel.com> (raw)
In-Reply-To: <1352992849-11219-1-git-send-email-daniel.vetter@ffwll.ch>

On Thu, 15 Nov 2012 16:20:49 +0100, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Since we drop dev->struct_mutex when going through the slowpath, the
> object might have been moved out of the cpu domain. Hence we need to
> clflush the entire object to ensure that after the ioctl returns,
> everything is coherent again (interwoven writes are ill-defined
> anyway).
> 
> But we only need to do this if we start in the cpu domain and the
> object requires flushing for coherency. So don't do the flushing if
> the object is coherent anyway or if we've done in-line clfushing
> already.
> 
> v2: i915_gem_clflush_object already checks whether the object is
> coherent and if so, drops the flushing. Hence we don't need to check
> that ourselves, simplifying the condition.
> 
Getting clearer, certainly. How about reversing the order of the
checks so that it reads as
  if (used-fast-path && fast-path-no-longer-valid) do_fixup()?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre