Re: [PATCH 07/10] drm/i915: Support for pread/pwrite from/to non shmem backed objects

From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org,
	akash.goel@intel.com, shashidhar.hiremath@intel.com
Subject: Re: [PATCH 07/10] drm/i915: Support for pread/pwrite from/to non shmem backed objects
Date: Mon, 11 Jan 2016 14:21:33 +0000	[thread overview]
Message-ID: <5693BA6D.2040402@linux.intel.com> (raw)
In-Reply-To: <20151222174009.GI5896@nuc-i3427.alporthouse.com>

On 22/12/15 17:40, Chris Wilson wrote:
> On Tue, Dec 22, 2015 at 11:58:33AM +0000, Tvrtko Ursulin wrote:
>> Maybe:
>>
>> 	if (!obj->base.filp || cpu_write_needs_clflush(obj))
>>     		ret = i915_gem_gtt_pwrite_fast(...);
>>
>> 	if (ret == -EFAULT && !obj->base.filp) {
>> 		ret = i915_gem_gtt_pwrite_slow(...) /* New function, doing the
>> slow_user_access loop for !filp objects, extracted from
>> gtt_pwrite_fast above. */
>
> The point is that "gtt_pwrite_slow" is going to be preferrable in the
> cases where it is possible. It just wasn't the full fallback patch for
> all objects previously, so we didn't bother to write a partial fallback
> handler.

Maybe I don't get this - is fast_user_write expected always to fail for 
non shmem backed objects? And so revert to the slow_user_path always and 
immediately? Because fast_user_write is still the primary choice for 
everything.

Perhaps this needs a matrix in the comment/commit describing which path 
for which objects and when..

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx