public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: oscar.mateo@intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/8] drm/i915: Rename ctx->id to ctx->handle
Date: Mon, 30 Jun 2014 13:53:34 -0700	[thread overview]
Message-ID: <20140630135334.00e7997f@jbarnes-desktop> (raw)
In-Reply-To: <1403789059-5692-5-git-send-email-oscar.mateo@intel.com>

On Thu, 26 Jun 2014 14:24:15 +0100
oscar.mateo@intel.com wrote:

> From: Oscar Mateo <oscar.mateo@intel.com>
> 
> This is an Execlists preparatory patch, since they make context ID become an
> overloaded term:
> 
> - In the software, it was used to distinguish which context userspace was
>   trying to use.
> - In the BSpec, the term is used to describe the 20-bits long field the
>   hardware uses to it to discriminate the contexts that are submitted to
>   the ELSP and inform the driver about their current status (via Context
>   Switch Interrupts and Context Status Buffers).
> 
> Initially, I tried to make the different meanings converge, but it proved
> impossible:
> 
> - The software ctx->id is per-filp, while the hardware one needs to be
>   globally unique.
> - Also, we multiplex several backing states objects per intel_context,
>   and all of them need unique HW IDs.
> - I tried adding a per-filp ID and then composing the HW context ID as:
>   ctx->id + file_priv->id + ring->id, but the fact that the hardware only
>   uses 20-bits means we have to artificially limit the number of filps or
>   contexts the userspace can create.
> 
> The ctx->handle bits are done with this Cocci patch (plus manual frobbing
> of the struct declaration):
> 
> 	@@
> 	struct intel_context c;
> 	@@
> 	- (c).id
> 	+ c.handle
> 
> 	@@
> 	struct intel_context *c;
> 	@@
> 	- (c)->id
> 	+ c->handle
> 
> Also, while we are at it, s/DEFAULT_CONTEXT_ID/DEFAULT_CONTEXT_HANDLE.
> 
> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c        |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h            |  6 +++---
>  drivers/gpu/drm/i915/i915_gem_context.c    | 12 ++++++------
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
>  drivers/gpu/drm/i915/intel_uncore.c        |  2 +-
>  5 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index d4b8391..7484e22 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1867,7 +1867,7 @@ static int per_file_ctx(int id, void *ptr, void *data)
>  	if (i915_gem_context_is_default(ctx))
>  		seq_puts(m, "  default context:\n");
>  	else
> -		seq_printf(m, "  context %d:\n", ctx->id);
> +		seq_printf(m, "  context %d:\n", ctx->handle);
>  	ppgtt->debug_dump(ppgtt, m);
>  
>  	return 0;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 122e942..5d2b6ab 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -584,10 +584,10 @@ struct i915_ctx_hang_stats {
>  };
>  
>  /* This must match up with the value previously used for execbuf2.rsvd1. */
> -#define DEFAULT_CONTEXT_ID 0
> +#define DEFAULT_CONTEXT_HANDLE 0
>  struct intel_context {
>  	struct kref ref;
> -	int id;
> +	int handle;
>  	bool rcs_is_initialized;
>  	uint8_t remap_slice;
>  	struct drm_i915_file_private *file_priv;
> @@ -2458,7 +2458,7 @@ static inline void i915_gem_context_unreference(struct intel_context *ctx)
>  
>  static inline bool i915_gem_context_is_default(const struct intel_context *c)
>  {
> -	return c->id == DEFAULT_CONTEXT_ID;
> +	return c->handle == DEFAULT_CONTEXT_HANDLE;
>  }
>  
>  int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
> index b8b9859..75e903f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -276,14 +276,14 @@ __create_hw_context(struct drm_device *dev,
>  	/* Default context will never have a file_priv */
>  	if (file_priv != NULL) {
>  		ret = idr_alloc(&file_priv->context_idr, ctx,
> -				DEFAULT_CONTEXT_ID, 0, GFP_KERNEL);
> +				DEFAULT_CONTEXT_HANDLE, 0, GFP_KERNEL);
>  		if (ret < 0)
>  			goto err_out;
>  	} else
> -		ret = DEFAULT_CONTEXT_ID;
> +		ret = DEFAULT_CONTEXT_HANDLE;
>  
>  	ctx->file_priv = file_priv;
> -	ctx->id = ret;
> +	ctx->handle = ret;
>  	/* NB: Mark all slices as needing a remap so that when the context first
>  	 * loads it will restore whatever remap state already exists. If there
>  	 * is no remap info, it will be a NOP. */
> @@ -787,7 +787,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
>  	if (IS_ERR(ctx))
>  		return PTR_ERR(ctx);
>  
> -	args->ctx_id = ctx->id;
> +	args->ctx_id = ctx->handle;
>  	DRM_DEBUG_DRIVER("HW context %d created\n", args->ctx_id);
>  
>  	return 0;
> @@ -801,7 +801,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
>  	struct intel_context *ctx;
>  	int ret;
>  
> -	if (args->ctx_id == DEFAULT_CONTEXT_ID)
> +	if (args->ctx_id == DEFAULT_CONTEXT_HANDLE)
>  		return -ENOENT;
>  
>  	ret = i915_mutex_lock_interruptible(dev);
> @@ -814,7 +814,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
>  		return PTR_ERR(ctx);
>  	}
>  
> -	idr_remove(&ctx->file_priv->context_idr, ctx->id);
> +	idr_remove(&ctx->file_priv->context_idr, ctx->handle);
>  	i915_gem_context_unreference(ctx);
>  	mutex_unlock(&dev->struct_mutex);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index d815ef5..c97178e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -938,7 +938,7 @@ i915_gem_validate_context(struct drm_device *dev, struct drm_file *file,
>  	struct intel_context *ctx = NULL;
>  	struct i915_ctx_hang_stats *hs;
>  
> -	if (ring->id != RCS && ctx_id != DEFAULT_CONTEXT_ID)
> +	if (ring->id != RCS && ctx_id != DEFAULT_CONTEXT_HANDLE)
>  		return ERR_PTR(-EINVAL);
>  
>  	ctx = i915_gem_context_get(file->driver_priv, ctx_id);
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index 29145df..e0f0843 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1010,7 +1010,7 @@ int i915_get_reset_stats_ioctl(struct drm_device *dev,
>  	if (args->flags || args->pad)
>  		return -EINVAL;
>  
> -	if (args->ctx_id == DEFAULT_CONTEXT_ID && !capable(CAP_SYS_ADMIN))
> +	if (args->ctx_id == DEFAULT_CONTEXT_HANDLE && !capable(CAP_SYS_ADMIN))
>  		return -EPERM;
>  
>  	ret = mutex_lock_interruptible(&dev->struct_mutex);

So this handle is just the sw tracking ID right?  Would be nice to have
a patch on top commenting that in the context struct (well commenting
the whole struct really).

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

-- 
Jesse Barnes, Intel Open Source Technology Center

  reply	other threads:[~2014-06-30 20:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-26 13:24 [PATCH 0/8] Execlists prep-work (II) oscar.mateo
2014-06-26 13:24 ` [PATCH 1/8] drm/i915: Extract context backing object allocation oscar.mateo
2014-06-30 20:46   ` Jesse Barnes
2014-06-26 13:24 ` [PATCH 2/8] drm/i915: Rename ctx->obj to ctx->rcs_state oscar.mateo
2014-06-30 20:49   ` Jesse Barnes
2014-07-03  9:46   ` Chris Wilson
2014-07-03 12:08     ` Mateo Lozano, Oscar
2014-07-03 12:28       ` Chris Wilson
2014-07-03 14:06         ` Mateo Lozano, Oscar
2014-06-26 13:24 ` [PATCH 3/8] drm/i915: Rename ctx->is_initialized to ctx->rcs_is_initialized oscar.mateo
2014-06-30 20:50   ` Jesse Barnes
2014-07-03  9:49   ` Chris Wilson
2014-07-03 12:09     ` Mateo Lozano, Oscar
2014-06-26 13:24 ` [PATCH 4/8] drm/i915: Rename ctx->id to ctx->handle oscar.mateo
2014-06-30 20:53   ` Jesse Barnes [this message]
2014-07-01 15:46     ` Mateo Lozano, Oscar
2014-07-01 16:07       ` Jesse Barnes
2014-07-03  9:30   ` Chris Wilson
2014-07-03  9:52     ` Chris Wilson
2014-07-03 12:01       ` Mateo Lozano, Oscar
2014-07-07 15:48         ` Daniel Vetter
2014-06-26 13:24 ` [PATCH 5/8] drm/i915: Extract ringbuffer destroy & generalize alloc to take a ringbuf oscar.mateo
2014-06-30 20:57   ` Jesse Barnes
2014-06-26 13:24 ` [PATCH 6/8] drm/i915: Generalize ring_space " oscar.mateo
2014-06-30 20:58   ` Jesse Barnes
2014-06-26 13:24 ` [PATCH 7/8] drm/i915: Generalize intel_ring_get_tail " oscar.mateo
2014-06-30 20:59   ` Jesse Barnes
2014-06-26 13:24 ` [PATCH 8/8] drm/i915: Extract the actual workload submission mechanism from execbuffer oscar.mateo
2014-06-30 21:02   ` Jesse Barnes
2014-07-03  7:32   ` Chris Wilson
2014-07-03  9:07     ` Mateo Lozano, Oscar
2014-07-03  9:28       ` 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=20140630135334.00e7997f@jbarnes-desktop \
    --to=jbarnes@virtuousgeek.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=oscar.mateo@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