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

[Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>]

On Mon, 2016-01-11 at 21:29 +0000, Chris Wilson wrote:
> On Mon, Jan 11, 2016 at 05:15:54PM +0000, Tvrtko Ursulin wrote:
> > > Is that not what was written? I take it my telepathy isn't working
> > > again.
> > 
> > Sorry not a new loop, new case in a old loop. This is the hunk I think
> > is not helping readability:
> > 
> > @@ -869,11 +967,29 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
> >  		/* If we get a fault while copying data, then (presumably) our
> >  		 * source page isn't available.  Return the error and we'll
> >  		 * retry in the slow path.
> > +		 * If the object is non-shmem backed, we retry again with the
> > +		 * path that handles page fault.
> >  		 */
> > -		if (fast_user_write(i915->gtt.mappable, page_base,
> > -				    page_offset, user_data, page_length)) {
> > -			ret = -EFAULT;
> > -			goto out_flush;
> > +		if (faulted || fast_user_write(i915->gtt.mappable,
> > +						page_base, page_offset,
> > +						user_data, page_length)) {
> > +			if (!obj->base.filp) {
> 
> This is just wrong, we neither need the faulted nor the difference in
> behaviour based on storage.
> -Chris
> 
Yes, this will not be required, I see. As we are planning to provide a
partial fallback for all objs (shmem backed as well as non-shmem
backed). 
So to conclude, a partial fallback (slow_user_access()) for all objs if
fast_user_write() fails.
And a full fallback (shmem_pwrite()) for only shmem backed objects if
slow_user_access() fails as well.
...

			hit_by_slowpath = 1;
                        mutex_unlock(&dev->struct_mutex);
                        if (slow_user_access(i915->gtt.mappable,
                                             page_base,
                                             page_offset, user_data,
                                             page_length, true)) {
                                ret = -EFAULT;
                                mutex_lock(&dev->struct_mutex);
                                goto out_flush;
                        }

                        mutex_lock(&dev->struct_mutex);

...

Thanks,
-Ankit

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