[Intel-gfx] [PATCH] drm/i915: allow stolen, pre-allocated objects to avoid GTT allocation

[Chris Wilson]

On Wed, May 08, 2013 at 09:36:29AM -0700, Jesse Barnes wrote:
> In some cases, we may not need GTT address space allocated to a stolen
> object, so allow passing -1 to the preallocated function to indicate as
> much.
> 
> Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c |    4 ++++
>  drivers/gpu/drm/i915/intel_pm.c        |    2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 9137fa4c..2e92861 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -360,6 +360,10 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
>  		return NULL;
>  	}
>  
> +	/* Some objects just need physical mem from stolen space */
> +	if (gtt_offset == -1)

For complete symmetry, we should do a
  list_add(&obj->gtt_list, &dev_priv->mm.unbound_list);
but as these bo are irrelevant for the shrinker there are no immediate
consequences. If we wanted to further complicate the code, we could
exclude stolen objects from unbound tracking entirely. Not worth it.

So as it stands, for completeness we should do the list_add here. Hmm,
actually, _i915_gem_object_create_stolen() should do the
list_add(unbound) and we should later do the list_move(bound) after
reserving the GTT space. Ok, ignore all of this and
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
(replacing -1 with a fancy name if some one else bikesheds :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre