From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 07/13] drm/i915: Allow userspace to clone contexts on creation
Date: Fri, 8 Mar 2019 16:13:56 +0000 [thread overview]
Message-ID: <cdac73cc-6f48-ac4d-c4e7-3d2a2d6dc8f8@linux.intel.com> (raw)
In-Reply-To: <20190308141244.16837-8-chris@chris-wilson.co.uk>
On 08/03/2019 14:12, Chris Wilson wrote:
> A usecase arose out of handling context recovery in mesa, whereby they
> wish to recreate a context with fresh logical state but preserving all
> other details of the original. Currently, they create a new context and
> iterate over which bits they want to copy across, but it would much more
> convenient if they were able to just pass in a target context to clone
> during creation. This essentially extends the setparam during creation
> to pull the details from a target context instead of the user supplied
> parameters.
This one is not used by media so it will likely have to find a separate
route upstream.
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 90 +++++++++++++++++++++++++
> include/uapi/drm/i915_drm.h | 14 ++++
> 2 files changed, 104 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
> index 310892b42b68..2cfc68b66944 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -1428,8 +1428,98 @@ static int create_setparam(struct i915_user_extension __user *ext, void *data)
> return ctx_setparam(data, &local.setparam);
> }
>
> +static int clone_sseu(struct i915_gem_context *dst,
> + struct i915_gem_context *src)
> +{
> + const struct intel_sseu default_sseu =
> + intel_device_default_sseu(dst->i915);
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> +
> + for_each_engine(engine, dst->i915, id) {
> + struct intel_context *ce;
> + struct intel_sseu sseu;
> +
> + ce = intel_context_lookup(src, engine);
> + if (!ce)
> + continue;
> +
> + sseu = ce->sseu;
> + if (!memcmp(&sseu, &default_sseu, sizeof(sseu)))
> + continue;
> +
> + ce = intel_context_pin_lock(dst, engine);
> + if (IS_ERR(ce))
> + return PTR_ERR(ce);
> +
> + ce->sseu = sseu;
> + intel_context_pin_unlock(ce);
> + }
> +
> + return 0;
> +}
> +
> +static int create_clone(struct i915_user_extension __user *ext, void *data)
> +{
> + struct drm_i915_gem_context_create_ext_clone local;
> + struct i915_gem_context *dst = data;
> + struct i915_gem_context *src;
> + int err;
> +
> + if (copy_from_user(&local, ext, sizeof(local)))
> + return -EFAULT;
> +
> + if (local.flags & I915_CONTEXT_CLONE_UNKNOWN)
> + return -EINVAL;
> +
> + if (local.rsvd)
> + return -EINVAL;
> +
> + if (local.clone == dst->user_handle) /* good guess! denied. */
> + return -ENOENT;
:) Good one, but put a more obvious comment like "Cannot clone itself!".
> +
> + rcu_read_lock();
> + src = __i915_gem_context_lookup_rcu(dst->file_priv, local.clone);
> + rcu_read_unlock();
> + if (!src)
> + return -ENOENT;
> +
> + GEM_BUG_ON(src == dst);
> +
> + if (local.flags & I915_CONTEXT_CLONE_FLAGS)
> + dst->user_flags = src->user_flags;
> +
> + if (local.flags & I915_CONTEXT_CLONE_SCHED)
> + dst->sched = src->sched;
> +
> + if (local.flags & I915_CONTEXT_CLONE_SSEU) {
> + err = clone_sseu(dst, src);
> + if (err)
> + return err;
> + }
> +
> + if (local.flags & I915_CONTEXT_CLONE_TIMELINE && src->timeline) {
Do we want to error out if no timeline and cloning was requested?
> + if (dst->timeline)
> + i915_timeline_put(dst->timeline);
> + dst->timeline = i915_timeline_get(src->timeline);
What prevents a different thread from changing either context in
parallel and making reference counting go bad?
> + }
> +
> + if (local.flags & I915_CONTEXT_CLONE_VM && src->ppgtt) {
Also fail if impossible was requested?
> + GEM_BUG_ON(dst->ppgtt == src->ppgtt);
Hm... what prevents this? Set_vm extension followed by clone could
trigger it I think.
> +
> + if (dst->ppgtt)
> + i915_ppgtt_put(dst->ppgtt);
> +
> + dst->ppgtt = i915_ppgtt_get(src->ppgtt);
> + i915_ppgtt_open(dst->ppgtt);
Also some locking is needed I think to make the exchange atomic.
Could use __assign_ppgtt?
> + }
> +
> + return 0;
> +}
> +
> static const i915_user_extension_fn create_extensions[] = {
> [I915_CONTEXT_CREATE_EXT_SETPARAM] = create_setparam,
> + [I915_CONTEXT_CREATE_EXT_CLONE] = create_clone,
> };
>
> static bool client_is_banned(struct drm_i915_file_private *file_priv)
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 007d77ff7295..50d154954d5f 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1579,6 +1579,20 @@ struct drm_i915_gem_context_create_ext_setparam {
> struct drm_i915_gem_context_param setparam;
> };
>
> +struct drm_i915_gem_context_create_ext_clone {
> +#define I915_CONTEXT_CREATE_EXT_CLONE 1
> + struct i915_user_extension base;
> + __u32 clone;
id, clone_id, source_id?
> + __u32 flags;
> +#define I915_CONTEXT_CLONE_FLAGS (1u << 0)
> +#define I915_CONTEXT_CLONE_SCHED (1u << 1)
> +#define I915_CONTEXT_CLONE_SSEU (1u << 2)
> +#define I915_CONTEXT_CLONE_TIMELINE (1u << 3)
> +#define I915_CONTEXT_CLONE_VM (1u << 4)
> +#define I915_CONTEXT_CLONE_UNKNOWN -(I915_CONTEXT_CLONE_VM << 1)
> + __u64 rsvd;
> +};
> +
> struct drm_i915_gem_context_destroy {
> __u32 ctx_id;
> __u32 pad;
>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-03-08 16:13 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 14:12 Home straight for veng, the uAPI wars Chris Wilson
2019-03-08 14:12 ` [PATCH 01/13] drm/i915: Suppress the "Failed to idle" warning for gem_eio Chris Wilson
2019-03-08 14:12 ` [PATCH 02/13] drm/i915: Introduce the i915_user_extension_method Chris Wilson
2019-03-08 14:33 ` Tvrtko Ursulin
2019-03-13 10:50 ` Chris Wilson
2019-03-13 11:13 ` Tvrtko Ursulin
2019-03-13 11:21 ` Chris Wilson
2019-03-13 11:35 ` Tvrtko Ursulin
2019-03-13 11:46 ` Chris Wilson
2019-03-13 13:11 ` Tvrtko Ursulin
2019-03-13 13:14 ` Chris Wilson
2019-03-08 14:12 ` [PATCH 03/13] drm/i915: Introduce a context barrier callback Chris Wilson
2019-03-08 14:12 ` [PATCH 04/13] drm/i915: Create/destroy VM (ppGTT) for use with contexts Chris Wilson
2019-03-08 15:03 ` Tvrtko Ursulin
2019-03-08 15:35 ` Chris Wilson
2019-03-08 15:41 ` [PATCH v2] " Chris Wilson
2019-03-08 14:12 ` [PATCH 05/13] drm/i915: Extend CONTEXT_CREATE to set parameters upon construction Chris Wilson
2019-03-08 14:12 ` [PATCH 06/13] drm/i915: Allow contexts to share a single timeline across all engines Chris Wilson
2019-03-08 15:56 ` Tvrtko Ursulin
2019-03-08 14:12 ` [PATCH 07/13] drm/i915: Allow userspace to clone contexts on creation Chris Wilson
2019-03-08 16:13 ` Tvrtko Ursulin [this message]
2019-03-08 16:34 ` Chris Wilson
2019-03-08 14:12 ` [PATCH 08/13] drm/i915: Allow a context to define its set of engines Chris Wilson
2019-03-08 16:27 ` Tvrtko Ursulin
2019-03-08 16:47 ` Chris Wilson
2019-03-11 9:23 ` Tvrtko Ursulin
2019-03-11 9:45 ` Chris Wilson
2019-03-11 10:12 ` Tvrtko Ursulin
2019-03-11 14:45 ` Chris Wilson
2019-03-11 16:16 ` Tvrtko Ursulin
2019-03-11 16:22 ` Chris Wilson
2019-03-11 16:34 ` Tvrtko Ursulin
2019-03-11 16:52 ` Chris Wilson
2019-03-08 14:12 ` [PATCH 09/13] drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[] Chris Wilson
2019-03-08 16:31 ` Tvrtko Ursulin
2019-03-08 16:57 ` Chris Wilson
2019-03-11 7:14 ` Tvrtko Ursulin
2019-03-11 10:33 ` Chris Wilson
2019-03-08 17:11 ` Chris Wilson
2019-03-11 7:16 ` Tvrtko Ursulin
2019-03-11 10:31 ` Chris Wilson
2019-03-08 14:12 ` [PATCH 10/13] drm/i915: Load balancing across a virtual engine Chris Wilson
2019-03-11 12:47 ` Tvrtko Ursulin
2019-03-11 13:43 ` Chris Wilson
2019-03-12 7:52 ` Tvrtko Ursulin
2019-03-12 8:56 ` Chris Wilson
2019-03-08 14:12 ` [PATCH 11/13] drm/i915: Extend execution fence to support a callback Chris Wilson
2019-03-11 13:09 ` Tvrtko Ursulin
2019-03-11 14:22 ` Chris Wilson
2019-03-08 14:12 ` [PATCH 12/13] drm/i915/execlists: Virtual engine bonding Chris Wilson
2019-03-11 13:38 ` Tvrtko Ursulin
2019-03-11 14:30 ` Chris Wilson
2019-03-08 14:12 ` [PATCH 13/13] drm/i915: Allow specification of parallel execbuf Chris Wilson
2019-03-11 13:40 ` Tvrtko Ursulin
2019-03-08 14:58 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/13] drm/i915: Suppress the "Failed to idle" warning for gem_eio Patchwork
2019-03-08 15:05 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-03-08 15:19 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-03-08 16:47 ` ✗ Fi.CI.BAT: failure for series starting with [01/13] drm/i915: Suppress the "Failed to idle" warning for gem_eio (rev2) Patchwork
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=cdac73cc-6f48-ac4d-c4e7-3d2a2d6dc8f8@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox