All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 01/16] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
Date: Wed, 29 Apr 2015 15:50:13 +0100	[thread overview]
Message-ID: <5540EFA5.1030002@linux.intel.com> (raw)
In-Reply-To: <1430138487-22541-2-git-send-email-chris@chris-wilson.co.uk>


On 04/27/2015 01:41 PM, Chris Wilson wrote:
> Since the remove of the pin-ioctl, we only care about not changing the
> cache level on buffers pinned to the hardware as indicated by
> obj->pin_display. So we can safely replace i915_gem_object_is_pinned()
> here with a plain obj->pin_display check. During rebinding, we will check
> sanity checks in case vma->pin_count is erroneously set.
>
> At the same time, we can micro-optimise GTT mmap() behaviour since we
> only need to relinquish the mmaps before Sandybridge.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/i915_gem.c | 33 +++++++++++++++++++++------------
>   1 file changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f0a6d03e9ba5..afdb604e4005 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3768,31 +3768,34 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
>   {
>   	struct drm_device *dev = obj->base.dev;
>   	struct i915_vma *vma, *next;
> +	bool bound = false;
>   	int ret;
>
>   	if (obj->cache_level == cache_level)
>   		return 0;
>
> -	if (i915_gem_obj_is_pinned(obj)) {
> +	if (obj->pin_display) {
>   		DRM_DEBUG("can not change the cache level of pinned objects\n");
>   		return -EBUSY;
>   	}
>
>   	list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) {
> +		if (!drm_mm_node_allocated(&vma->node))
> +			continue;
> +

Another micro-optimisation?

Side note - this was puzzling and then I realized 
i915_gem_valid_gtt_space says true when node is not allocated. It seems 
to be only concerned by node colouring - so is that one badly name 
function or I am missing something?

>   		if (!i915_gem_valid_gtt_space(vma, cache_level)) {
>   			ret = i915_vma_unbind(vma);
>   			if (ret)
>   				return ret;
> -		}
> +		} else
> +			bound = true;
>   	}
>
> -	if (i915_gem_obj_bound_any(obj)) {
> +	if (bound) {
>   		ret = i915_gem_object_finish_gpu(obj);
>   		if (ret)
>   			return ret;
>
> -		i915_gem_object_finish_gtt(obj);
> -
>   		/* Before SandyBridge, you could not use tiling or fence
>   		 * registers with snooped memory, so relinquish any fences
>   		 * currently pointing to our region in the aperture.
> @@ -3801,15 +3804,21 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
>   			ret = i915_gem_object_put_fence(obj);
>   			if (ret)
>   				return ret;
> +
> +			i915_gem_release_mmap(obj);
>   		}

If only < gen6 we need to drop the mmap, what happens with the domain 
tracking - who removes the GTT bit from there now?

>
> -		list_for_each_entry(vma, &obj->vma_list, vma_link)
> -			if (drm_mm_node_allocated(&vma->node)) {
> -				ret = i915_vma_bind(vma, cache_level,
> -						    PIN_UPDATE);
> -				if (ret)
> -					return ret;
> -			}
> +		list_for_each_entry(vma, &obj->vma_list, vma_link) {
> +			if (!drm_mm_node_allocated(&vma->node))
> +				continue;
> +
> +			if (vma->pin_count)
> +				return -EBUSY;

Preserve DRM_DEBUG as it was before?

Regards,

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

  reply	other threads:[~2015-04-29 14:50 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27 12:41 RPS tuning Chris Wilson
2015-04-27 12:41 ` [PATCH 01/16] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level Chris Wilson
2015-04-29 14:50   ` Tvrtko Ursulin [this message]
2015-04-29 15:15     ` Chris Wilson
2015-04-27 12:41 ` [PATCH 02/16] drm/i915: Only remove objects pinned to the display from the available aperture Chris Wilson
2015-04-29 15:05   ` Tvrtko Ursulin
2015-04-29 15:48     ` Chris Wilson
2015-04-27 12:41 ` [PATCH 03/16] drm/i915: Remove domain flubbing from i915_gem_object_finish_gpu() Chris Wilson
2015-05-11 16:43   ` Daniel Vetter
2015-04-27 12:41 ` [PATCH 04/16] drm/i915: Ensure cache flushes prior to doing CS flips Chris Wilson
2015-05-11 16:46   ` Daniel Vetter
2015-04-27 12:41 ` [PATCH 05/16] drm/i915: Fix race on unreferencing the wrong mmio-flip-request Chris Wilson
2015-05-11 16:51   ` Daniel Vetter
2015-05-11 20:23     ` Chris Wilson
2015-05-12  8:43       ` Daniel Vetter
2015-04-27 12:41 ` [PATCH 06/16] drm/i915: Implement inter-engine read-read optimisations Chris Wilson
2015-04-29 13:51   ` Tvrtko Ursulin
2015-04-27 12:41 ` [PATCH 07/16] drm/i915: Inline check required for object syncing prior to execbuf Chris Wilson
2015-04-29 14:03   ` Tvrtko Ursulin
2015-04-29 14:22     ` Chris Wilson
2015-04-27 12:41 ` [PATCH 08/16] drm/i915: Add RPS thresholds to debugfs/i915_frequency_info Chris Wilson
2015-05-04 14:36   ` Daniel Vetter
2015-04-27 12:41 ` [PATCH 09/16] drm/i915: Limit ring synchronisation (sw sempahores) RPS boosts Chris Wilson
2015-05-04 14:38   ` Daniel Vetter
2015-05-04 14:46     ` Daniel Vetter
2015-04-27 12:41 ` [PATCH 10/16] drm/i915: Limit mmio flip " Chris Wilson
2015-04-27 12:41 ` [PATCH 11/16] drm/i915: Convert RPS tracking to a intel_rps_client struct Chris Wilson
2015-04-27 12:41 ` [PATCH 12/16] drm/i915: Don't downclock whilst we have clients waiting for GPU results Chris Wilson
2015-04-27 12:41 ` [PATCH 13/16] drm/i915: Free RPS boosts for all laggards Chris Wilson
2015-05-21 12:50   ` Daniel Vetter
2015-05-21 12:56   ` Daniel Vetter
2015-04-27 12:41 ` [PATCH 14/16] drm/i915: Make the RPS interface gen agnostic Chris Wilson
2015-04-27 12:41 ` [PATCH 15/16] drm/i915, intel_ips: Enable GPU wait-boosting with IPS Chris Wilson
2015-04-27 12:41 ` [PATCH 16/16] drm/i915: Allow RPS waitboosting to use max GPU frequency Chris Wilson
2015-05-04 14:51   ` Daniel Vetter
2015-05-04 14:58     ` Chris Wilson
2015-05-21 12:55   ` Daniel Vetter
2015-05-21 13:05     ` 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=5540EFA5.1030002@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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.