All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <John.C.Harrison@Intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/5] drm/i915: Tidy batch pool logic
Date: Fri, 13 Feb 2015 14:00:50 +0000	[thread overview]
Message-ID: <54DE0392.7060809@Intel.com> (raw)
In-Reply-To: <1421234459-21424-5-git-send-email-chris@chris-wilson.co.uk>


On 14/01/2015 11:20, Chris Wilson wrote:
> Move the madvise logic out of the execbuffer main path into the
> relatively rare allocation path, making the execbuffer manipulation less
> fragile.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/i915_cmd_parser.c     | 12 +++---------
>   drivers/gpu/drm/i915/i915_gem_batch_pool.c | 31 +++++++++++++++---------------
>   drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +++--------
>   3 files changed, 21 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 9a6da3536ae5..3e5e8cb54a88 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -866,6 +866,9 @@ static u32 *copy_batch(struct drm_i915_gem_object *dest_obj,
>   	    batch_len + batch_start_offset > src_obj->base.size)
>   		return ERR_PTR(-E2BIG);
>   
> +	if (WARN_ON(dest_obj->pages_pin_count == 0))
> +		return ERR_PTR(-ENODEV);
> +
>   	ret = i915_gem_obj_prepare_shmem_read(src_obj, &needs_clflush);
>   	if (ret) {
>   		DRM_DEBUG_DRIVER("CMD: failed to prepare shadow batch\n");
> @@ -879,13 +882,6 @@ static u32 *copy_batch(struct drm_i915_gem_object *dest_obj,
>   		goto unpin_src;
>   	}
>   
> -	ret = i915_gem_object_get_pages(dest_obj);
> -	if (ret) {
> -		DRM_DEBUG_DRIVER("CMD: Failed to get pages for shadow batch\n");
> -		goto unmap_src;
> -	}
> -	i915_gem_object_pin_pages(dest_obj);
> -
>   	ret = i915_gem_object_set_to_cpu_domain(dest_obj, true);
>   	if (ret) {
>   		DRM_DEBUG_DRIVER("CMD: Failed to set shadow batch to CPU\n");
> @@ -895,7 +891,6 @@ static u32 *copy_batch(struct drm_i915_gem_object *dest_obj,
>   	dst = vmap_batch(dest_obj, 0, batch_len);
>   	if (!dst) {
>   		DRM_DEBUG_DRIVER("CMD: Failed to vmap shadow batch\n");
> -		i915_gem_object_unpin_pages(dest_obj);
>   		ret = -ENOMEM;
>   		goto unmap_src;
>   	}
> @@ -1126,7 +1121,6 @@ int i915_parse_cmds(struct intel_engine_cs *ring,
>   	}
>   
>   	vunmap(batch_base);
> -	i915_gem_object_unpin_pages(shadow_batch_obj);
>   
>   	return ret;
>   }
> diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
> index c690170a1c4f..e5c88ddd8452 100644
> --- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
> +++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
> @@ -66,9 +66,7 @@ void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool)
>   					 struct drm_i915_gem_object,
>   					 batch_pool_list);
>   
> -		WARN_ON(obj->active);
> -
> -		list_del_init(&obj->batch_pool_list);
> +		list_del(&obj->batch_pool_list);
>   		drm_gem_object_unreference(&obj->base);
>   	}
>   }
> @@ -96,10 +94,9 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
>   	WARN_ON(!mutex_is_locked(&pool->dev->struct_mutex));
>   
>   	list_for_each_entry_safe(tmp, next,
> -			&pool->cache_list, batch_pool_list) {
> -
> +				 &pool->cache_list, batch_pool_list) {
>   		if (tmp->active)
> -			continue;
> +			break;
>   
>   		/* While we're looping, do some clean up */
>   		if (tmp->madv == __I915_MADV_PURGED) {
> @@ -113,25 +110,27 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
>   		 * but not 'too much' bigger. A better way to do this
>   		 * might be to bucket the pool objects based on size.
>   		 */
> -		if (tmp->base.size >= size &&
> -		    tmp->base.size <= (2 * size)) {
> +		if (tmp->base.size >= size && tmp->base.size <= 2 * size) {
>   			obj = tmp;
>   			break;
>   		}
>   	}
>   
> -	if (!obj) {
> +	if (obj == NULL) {
> +		int ret;
> +
>   		obj = i915_gem_alloc_object(pool->dev, size);
> -		if (!obj)
> +		if (obj == NULL)
>   			return ERR_PTR(-ENOMEM);
>   
> -		list_add_tail(&obj->batch_pool_list, &pool->cache_list);
> -	}
> -	else
> -		/* Keep list in LRU order */
> -		list_move_tail(&obj->batch_pool_list, &pool->cache_list);
> +		ret = i915_gem_object_get_pages(obj);
> +		if (ret)
> +			return ERR_PTR(ret);
>   
> -	obj->madv = I915_MADV_WILLNEED;
> +		obj->madv = I915_MADV_DONTNEED;
> +	}
>   
> +	list_move_tail(&obj->batch_pool_list, &pool->cache_list);
Why is it now safe to do a move_tail instead of add_tail if the node has 
just been allocated? Was the original add_tail() wrong or am I not 
spotting some critical difference to how new pool objects are created?
> +	i915_gem_object_pin_pages(obj);
Is it worth updating the function description comment to add a line 
about the returned buffer now being pinned and the caller must worry 
about unpinning it?

>   	return obj;
>   }
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 3fbd5212225f..6357f01e6c46 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -37,7 +37,6 @@
>   #define  __EXEC_OBJECT_HAS_FENCE (1<<30)
>   #define  __EXEC_OBJECT_NEEDS_MAP (1<<29)
>   #define  __EXEC_OBJECT_NEEDS_BIAS (1<<28)
> -#define  __EXEC_OBJECT_PURGEABLE (1<<27)
>   
>   #define BATCH_OFFSET_BIAS (256*1024)
>   
> @@ -224,12 +223,7 @@ i915_gem_execbuffer_unreserve_vma(struct i915_vma *vma)
>   	if (entry->flags & __EXEC_OBJECT_HAS_PIN)
>   		vma->pin_count--;
>   
> -	if (entry->flags & __EXEC_OBJECT_PURGEABLE)
> -		obj->madv = I915_MADV_DONTNEED;
> -
> -	entry->flags &= ~(__EXEC_OBJECT_HAS_FENCE |
> -			  __EXEC_OBJECT_HAS_PIN |
> -			  __EXEC_OBJECT_PURGEABLE);
> +	entry->flags &= ~(__EXEC_OBJECT_HAS_FENCE | __EXEC_OBJECT_HAS_PIN);
>   }
>   
>   static void eb_destroy(struct eb_vmas *eb)
> @@ -1154,6 +1148,7 @@ i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
>   			      batch_start_offset,
>   			      batch_len,
>   			      is_master);
> +	i915_gem_object_unpin_pages(shadow_batch_obj);
>   	if (ret)
>   		goto err;
>   
> @@ -1165,7 +1160,7 @@ i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
>   
>   	vma = i915_gem_obj_to_ggtt(shadow_batch_obj);
>   	vma->exec_entry = shadow_exec_entry;
> -	vma->exec_entry->flags = __EXEC_OBJECT_PURGEABLE | __EXEC_OBJECT_HAS_PIN;
> +	vma->exec_entry->flags = __EXEC_OBJECT_HAS_PIN;
>   	drm_gem_object_reference(&shadow_batch_obj->base);
>   	list_add_tail(&vma->exec_list, &eb->vmas);
>   

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

  parent reply	other threads:[~2015-02-13 14:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-14 11:20 [PATCH 1/5] agp/intel: Serialise after GTT updates Chris Wilson
2015-01-14 11:20 ` [PATCH 2/5] drm/i915: Fallback to using CPU relocations for large batch buffers Chris Wilson
2015-01-15  9:45   ` Daniel, Thomas
2015-01-26  8:57   ` Jani Nikula
2015-01-27 15:09   ` Daniel Vetter
2015-01-27 21:43     ` Chris Wilson
2015-01-28  9:14       ` Daniel Vetter
2015-01-28  9:34         ` Chris Wilson
2015-01-14 11:20 ` [PATCH 3/5] drm/i915: Trim the command parser allocations Chris Wilson
2015-02-13 13:08   ` John Harrison
2015-02-13 13:23     ` Chris Wilson
2015-02-13 16:43       ` John Harrison
2015-02-23 16:09         ` Daniel Vetter
2015-01-14 11:20 ` [PATCH 4/5] drm/i915: Cache last obj->pages location for i915_gem_object_get_page() Chris Wilson
2015-02-13 13:33   ` John Harrison
2015-02-13 13:35   ` John Harrison
2015-02-13 14:28     ` Chris Wilson
2015-01-14 11:20 ` [PATCH 5/5] drm/i915: Tidy batch pool logic Chris Wilson
2015-01-14 20:54   ` shuang.he
2015-02-13 14:00   ` John Harrison [this message]
2015-02-13 14:57     ` Chris Wilson
2015-01-26 10:47 ` [PATCH v2] agp/intel: Serialise after GTT updates Chris Wilson
2015-01-27 14:58   ` Daniel Vetter
2015-01-27 21:44     ` Chris Wilson
2015-01-28  9:15       ` Daniel Vetter
2015-01-28  7:50   ` shuang.he
2015-02-06  0:11 ` [PATCH 1/5] " Jesse Barnes
2015-02-06  8:31   ` Chris Wilson
2015-02-06  8:32   ` Daniel Vetter
2015-02-13  8:59     ` Ville Syrjälä
2015-02-13  9:25       ` Chris Wilson

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=54DE0392.7060809@Intel.com \
    --to=john.c.harrison@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.