intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org
Cc: 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: Tue, 22 Dec 2015 11:58:33 +0000	[thread overview]
Message-ID: <56793AE9.5090300@linux.intel.com> (raw)
In-Reply-To: <1450765253-32104-8-git-send-email-ankitprasad.r.sharma@intel.com>



On 22/12/15 06:20, ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>
> This patch adds support for extending the pread/pwrite functionality
> for objects not backed by shmem. The access will be made through
> gtt interface. This will cover objects backed by stolen memory as well
> as other non-shmem backed objects.
>
> v2: Drop locks around slow_user_access, prefault the pages before
> access (Chris)
>
> v3: Rebased to the latest drm-intel-nightly (Ankit)
>
> v4: Moved page base & offset calculations outside the copy loop,
> corrected data types for size and offset variables, corrected if-else
> braces format (Tvrtko/kerneldocs)
>
> v5: Enabled pread/pwrite for all non-shmem backed objects including
> without tiling restrictions (Ankit)
>
> v6: Using pwrite_fast for non-shmem backed objects as well (Chris)
>
> v7: Updated commit message, Renamed i915_gem_gtt_read to i915_gem_gtt_copy,
> added pwrite slow path for non-shmem backed objects (Chris/Tvrtko)
>
> v8: Updated v7 commit message, mutex unlock around pwrite slow path for
> non-shmem backed objects (Tvrtko)
>
> v9: Corrected check during pread_ioctl, to avoid shmem_pread being
> called for non-shmem backed objects (Tvrtko)
>
> v10: Moved the write_domain check to needs_clflush and tiling mode check
> to pwrite_fast (Chris)
>
> Testcase: igt/gem_stolen
>
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_gem.c | 162 +++++++++++++++++++++++++++++++++-------
>   1 file changed, 134 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 4789c64..a0ec1a9 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -55,6 +55,9 @@ static bool cpu_cache_is_coherent(struct drm_device *dev,
>
>   static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
>   {
> +	if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> +		return false;
> +
>   	if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
>   		return true;
>
> @@ -631,6 +634,99 @@ shmem_pread_slow(struct page *page, int shmem_page_offset, int page_length,
>   	return ret ? - EFAULT : 0;
>   }
>
> +static inline uint64_t
> +slow_user_access(struct io_mapping *mapping,
> +		 uint64_t page_base, int page_offset,
> +		 char __user *user_data,
> +		 int length, bool pwrite)
> +{
> +	void __iomem *vaddr_inatomic;
> +	void *vaddr;
> +	uint64_t unwritten;
> +
> +	vaddr_inatomic = io_mapping_map_wc(mapping, page_base);
> +	/* We can use the cpu mem copy function because this is X86. */
> +	vaddr = (void __force *)vaddr_inatomic + page_offset;
> +	if (pwrite)
> +		unwritten = __copy_from_user(vaddr, user_data, length);
> +	else
> +		unwritten = __copy_to_user(user_data, vaddr, length);
> +
> +	io_mapping_unmap(vaddr_inatomic);
> +	return unwritten;
> +}
> +
> +static int
> +i915_gem_gtt_copy(struct drm_device *dev,
> +		   struct drm_i915_gem_object *obj, uint64_t size,
> +		   uint64_t data_offset, uint64_t data_ptr)
> +{
> +	struct drm_i915_private *dev_priv = dev->dev_private;
> +	char __user *user_data;
> +	uint64_t remain;
> +	uint64_t offset, page_base;
> +	int page_offset, page_length, ret = 0;
> +
> +	ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
> +	if (ret)
> +		goto out;
> +
> +	ret = i915_gem_object_set_to_gtt_domain(obj, false);
> +	if (ret)
> +		goto out_unpin;
> +
> +	ret = i915_gem_object_put_fence(obj);
> +	if (ret)
> +		goto out_unpin;
> +
> +	user_data = to_user_ptr(data_ptr);
> +	remain = size;
> +	offset = i915_gem_obj_ggtt_offset(obj) + data_offset;
> +
> +	mutex_unlock(&dev->struct_mutex);
> +	if (likely(!i915.prefault_disable))
> +		ret = fault_in_multipages_writeable(user_data, remain);
> +
> +	/*
> +	 * page_offset = offset within page
> +	 * page_base = page offset within aperture
> +	 */
> +	page_offset = offset_in_page(offset);
> +	page_base = offset & PAGE_MASK;
> +
> +	while (remain > 0) {
> +		/* page_length = bytes to copy for this page */
> +		page_length = remain;
> +		if ((page_offset + remain) > PAGE_SIZE)
> +			page_length = PAGE_SIZE - page_offset;
> +
> +		/* This is a slow read/write as it tries to read from
> +		 * and write to user memory which may result into page
> +		 * faults
> +		 */
> +		ret = slow_user_access(dev_priv->gtt.mappable, page_base,
> +				       page_offset, user_data,
> +				       page_length, false);
> +
> +		if (ret) {
> +			ret = -EFAULT;
> +			break;
> +		}
> +
> +		remain -= page_length;
> +		user_data += page_length;
> +		page_base += page_length;
> +		page_offset = 0;
> +	}
> +
> +	mutex_lock(&dev->struct_mutex);
> +
> +out_unpin:
> +	i915_gem_object_ggtt_unpin(obj);
> +out:
> +	return ret;
> +}
> +
>   static int
>   i915_gem_shmem_pread(struct drm_device *dev,
>   		     struct drm_i915_gem_object *obj,
> @@ -754,17 +850,14 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
>   		goto out;
>   	}
>
> -	/* prime objects have no backing filp to GEM pread/pwrite
> -	 * pages from.
> -	 */
> -	if (!obj->base.filp) {
> -		ret = -EINVAL;
> -		goto out;
> -	}
> -
>   	trace_i915_gem_object_pread(obj, args->offset, args->size);
>
> -	ret = i915_gem_shmem_pread(dev, obj, args, file);
> +	/* pread for non shmem backed objects */
> +	if (!obj->base.filp && obj->tiling_mode == I915_TILING_NONE)
> +		ret = i915_gem_gtt_copy(dev, obj, args->size,
> +					args->offset, args->data_ptr);
> +	else if (obj->base.filp)
> +		ret = i915_gem_shmem_pread(dev, obj, args, file);
>
>   out:
>   	drm_gem_object_unreference(&obj->base);
> @@ -806,10 +899,15 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
>   			 struct drm_i915_gem_pwrite *args,
>   			 struct drm_file *file)
>   {
> +	struct drm_device *dev = obj->base.dev;
>   	struct drm_mm_node node;
>   	uint64_t remain, offset;
>   	char __user *user_data;
>   	int ret;
> +	bool faulted = false;
> +
> +	if (obj->tiling_mode != I915_TILING_NONE)
> +		return -EFAULT;

I am pretty sure we can't return -EFAULT for this since it would be very 
misleading. -EINVAL?

>
>   	ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE | PIN_NONBLOCK);
>   	if (ret) {
> @@ -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) {
> +				faulted = true;
> +				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);
> +			} else {
> +				ret = -EFAULT;
> +				goto out_flush;
> +			}
>   		}
>
>   		remain -= page_length;
> @@ -1140,14 +1256,6 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
>   		goto out;
>   	}
>
> -	/* prime objects have no backing filp to GEM pread/pwrite
> -	 * pages from.
> -	 */
> -	if (!obj->base.filp) {
> -		ret = -EINVAL;
> -		goto out;
> -	}
> -
>   	trace_i915_gem_object_pwrite(obj, args->offset, args->size);
>
>   	ret = -EFAULT;
> @@ -1157,9 +1265,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
>   	 * pread/pwrite currently are reading and writing from the CPU
>   	 * perspective, requiring manual detiling by the client.
>   	 */
> -	if (obj->tiling_mode == I915_TILING_NONE &&
> -	    obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
> -	    cpu_write_needs_clflush(obj)) {
> +	if (!obj->base.filp || cpu_write_needs_clflush(obj)) {
>   		ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
>   		/* Note that the gtt paths might fail with non-page-backed user
>   		 * pointers (e.g. gtt mappings when moving data between
> @@ -1169,8 +1275,10 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
>   	if (ret == -EFAULT || ret == -ENOSPC) {

Does the objectionable -EFAULT I commented on above serve as a way to 
hit this path here?

Would it be better to be more explicit in handling of pwrite paths for 
different object types? It could also simplify the main loop in 
i915_gem_gtt_pwrite_fast which I still really dislike.

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. */
	} else if (ret == -EFAULT || ret == -ENOSPC) {
		if (obj->phys_handle)
			...
		...

Not sure that I got it right, but it would be much more readable and 
decoupled if possible. Thoughts?

>   		if (obj->phys_handle)
>   			ret = i915_gem_phys_pwrite(obj, args, file);
> -		else
> +		else if (obj->base.filp)
>   			ret = i915_gem_shmem_pwrite(dev, obj, args, file);
> +		else
> +			ret = -ENODEV;
>   	}
>
>   out:
> @@ -3892,9 +4000,7 @@ out:
>   	 * object is now coherent at its new cache level (with respect
>   	 * to the access domain).
>   	 */
> -	if (obj->cache_dirty &&
> -	    obj->base.write_domain != I915_GEM_DOMAIN_CPU &&
> -	    cpu_write_needs_clflush(obj)) {
> +	if (obj->cache_dirty && cpu_write_needs_clflush(obj)) {
>   		if (i915_gem_clflush_object(obj, true))
>   			i915_gem_chipset_flush(obj->base.dev);
>   	}
>

Regards,

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

  reply	other threads:[~2015-12-22 11:58 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-22  6:20 [PATCH v13 0/10] Support for creating/using Stolen memory backed objects ankitprasad.r.sharma
2015-12-22  6:20 ` [PATCH 01/10] drm/i915: Allow use of get_dma_address for stolen " ankitprasad.r.sharma
2015-12-22 10:23   ` Tvrtko Ursulin
2015-12-22 10:39     ` Chris Wilson
2016-01-05 16:47       ` Daniel Vetter
2015-12-22  6:20 ` [PATCH 02/10] drm/i915: Use insert_page for pwrite_fast ankitprasad.r.sharma
2015-12-22  6:55   ` kbuild test robot
2015-12-22 10:44   ` Tvrtko Ursulin
2015-12-22 11:15     ` Ankitprasad Sharma
2015-12-22 11:52       ` Chris Wilson
2015-12-22 12:03         ` Tvrtko Ursulin
2015-12-22 13:38           ` Chris Wilson
2015-12-22  6:20 ` [PATCH 03/10] drm/i915: Clearing buffer objects via CPU/GTT ankitprasad.r.sharma
2015-12-22 11:09   ` Tvrtko Ursulin
2015-12-22  6:20 ` [PATCH 04/10] drm/i915: Support for creating Stolen memory backed objects ankitprasad.r.sharma
2016-01-12 12:45   ` Chris Wilson
2015-12-22  6:20 ` [PATCH 05/10] drm/i915: Propagating correct error codes to the userspace ankitprasad.r.sharma
2015-12-22 11:20   ` Tvrtko Ursulin
2015-12-22 11:29     ` Ankitprasad Sharma
2015-12-22 12:02       ` Tvrtko Ursulin
2016-01-06  7:45         ` Daniel Vetter
2015-12-22  6:20 ` [PATCH 06/10] drm/i915: Add support for stealing purgable stolen pages ankitprasad.r.sharma
2015-12-22 11:22   ` Tvrtko Ursulin
2015-12-22  6:20 ` [PATCH 07/10] drm/i915: Support for pread/pwrite from/to non shmem backed objects ankitprasad.r.sharma
2015-12-22 11:58   ` Tvrtko Ursulin [this message]
2015-12-22 17:40     ` Chris Wilson
2016-01-11 14:21       ` Tvrtko Ursulin
2016-01-11 14:45         ` Chris Wilson
2016-01-11 15:11           ` Tvrtko Ursulin
2016-01-11 17:03             ` Chris Wilson
2016-01-11 17:15               ` Tvrtko Ursulin
2016-01-11 21:29                 ` Chris Wilson
2016-01-12  7:50                   ` Ankitprasad Sharma
2015-12-22  6:20 ` [PATCH 08/10] drm/i915: Migrate stolen objects before hibernation ankitprasad.r.sharma
2015-12-22 12:33   ` Tvrtko Ursulin
2015-12-22 17:02     ` Chris Wilson
2015-12-22 17:14       ` Tvrtko Ursulin
2016-01-06  7:48         ` Daniel Vetter
2015-12-22 17:23     ` Tvrtko Ursulin
2015-12-22  6:20 ` [PATCH 09/10] acpi: Export acpi_bus_type ankitprasad.r.sharma
2015-12-22 16:41   ` Tvrtko Ursulin
2016-01-06  7:51     ` Daniel Vetter
2015-12-22  6:20 ` [PATCH 10/10] drm/i915: Disable use of stolen area by User when Intel RST is present ankitprasad.r.sharma
2015-12-22 12:44   ` Tvrtko Ursulin
2015-12-22 13:14   ` Chris Wilson
2016-01-06  7:52   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56793AE9.5090300@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=akash.goel@intel.com \
    --cc=ankitprasad.r.sharma@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=shashidhar.hiremath@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).