dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Jason Ekstrand <jason@jlekstrand.net>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 13/21] drm/i915/gem: Add an intermediate proto_context struct
Date: Thu, 29 Apr 2021 15:02:54 +0200	[thread overview]
Message-ID: <YIqufo0AsyRndhav@phenom.ffwll.local> (raw)
In-Reply-To: <20210423223131.879208-14-jason@jlekstrand.net>

The commit introducing a new data structure really should have a solid
intro in the commit message about. Please cover

- that ctx really should be immutable, safe for exceptions like priority

- that unfortunately we butchered the uapi with setparam and sharing
  setparams between create_ext and setparam

- and how exactly proto ctx fixes this (with stuff like locking design
  used)

Maybe also dupe the kerneldoc into here for completeness.
On Fri, Apr 23, 2021 at 05:31:23PM -0500, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 143 ++++++++++++++----
>  .../gpu/drm/i915/gem/i915_gem_context_types.h |  21 +++
>  .../gpu/drm/i915/gem/selftests/mock_context.c |  16 +-

I'm wondering whether in the end we should split out the proto_ctx into
its own file, with the struct private only to itself. But I guess
impossible during the transition, and also maybe afterwards?

>  3 files changed, 150 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index e5efd22c89ba2..3e883daab93bf 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -191,6 +191,95 @@ static int validate_priority(struct drm_i915_private *i915,
>  	return 0;
>  }
>  
> +static void proto_context_close(struct i915_gem_proto_context *pc)
> +{
> +	if (pc->vm)
> +		i915_vm_put(pc->vm);
> +	kfree(pc);
> +}
> +
> +static int proto_context_set_persistence(struct drm_i915_private *i915,
> +					 struct i915_gem_proto_context *pc,
> +					 bool persist)
> +{
> +	if (test_bit(UCONTEXT_PERSISTENCE, &pc->user_flags) == persist)
> +		return 0;

We have compilers to optimize this kind of stuff, pls remove :-)
Especially with the non-atomic bitops there's no point.

> +
> +	if (persist) {
> +		/*
> +		 * Only contexts that are short-lived [that will expire or be
> +		 * reset] are allowed to survive past termination. We require
> +		 * hangcheck to ensure that the persistent requests are healthy.
> +		 */
> +		if (!i915->params.enable_hangcheck)
> +			return -EINVAL;
> +
> +		set_bit(UCONTEXT_PERSISTENCE, &pc->user_flags);

It's a bit entetaining, but the bitops in the kernel are atomic. Which is
hella confusing here.

I think open coding is the standard for truly normal bitops.

> +	} else {
> +		/* To cancel a context we use "preempt-to-idle" */
> +		if (!(i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
> +			return -ENODEV;
> +
> +		/*
> +		 * If the cancel fails, we then need to reset, cleanly!
> +		 *
> +		 * If the per-engine reset fails, all hope is lost! We resort
> +		 * to a full GPU reset in that unlikely case, but realistically
> +		 * if the engine could not reset, the full reset does not fare
> +		 * much better. The damage has been done.
> +		 *
> +		 * However, if we cannot reset an engine by itself, we cannot
> +		 * cleanup a hanging persistent context without causing
> +		 * colateral damage, and we should not pretend we can by
> +		 * exposing the interface.
> +		 */
> +		if (!intel_has_reset_engine(&i915->gt))
> +			return -ENODEV;
> +
> +		clear_bit(UCONTEXT_PERSISTENCE, &pc->user_flags);

Same here.

> +	}
> +
> +	return 0;
> +}
> +
> +static struct i915_gem_proto_context *
> +proto_context_create(struct drm_i915_private *i915, unsigned int flags)
> +{
> +	struct i915_gem_proto_context *pc;
> +
> +	if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> +	    !HAS_EXECLISTS(i915))
> +		return ERR_PTR(-EINVAL);
> +
> +	pc = kzalloc(sizeof(*pc), GFP_KERNEL);
> +	if (!pc)
> +		return ERR_PTR(-ENOMEM);
> +
> +	if (HAS_FULL_PPGTT(i915)) {
> +		struct i915_ppgtt *ppgtt;
> +
> +		ppgtt = i915_ppgtt_create(&i915->gt);
> +		if (IS_ERR(ppgtt)) {
> +			drm_dbg(&i915->drm, "PPGTT setup failed (%ld)\n",
> +				PTR_ERR(ppgtt));
> +			proto_context_close(pc);
> +			return ERR_CAST(ppgtt);
> +		}
> +		pc->vm = &ppgtt->vm;
> +	}
> +
> +	pc->user_flags = 0;
> +	set_bit(UCONTEXT_BANNABLE, &pc->user_flags);
> +	set_bit(UCONTEXT_RECOVERABLE, &pc->user_flags);

Same about atomic bitops here.

> +	proto_context_set_persistence(i915, pc, true);
> +	pc->sched.priority = I915_PRIORITY_NORMAL;
> +
> +	if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE)
> +		pc->single_timeline = true;

bit a bikeshed, but I'd put the error checking in here too and deal with
the unwind pain with the usual goto proto_close. That should also make the
ppgtt unwind path a bit clearer because it sticks out in the standard way.

> +
> +	return pc;
> +}
> +
>  static struct i915_address_space *
>  context_get_vm_rcu(struct i915_gem_context *ctx)
>  {
> @@ -660,7 +749,8 @@ static int __context_set_persistence(struct i915_gem_context *ctx, bool state)
>  }
>  
>  static struct i915_gem_context *
> -__create_context(struct drm_i915_private *i915)
> +__create_context(struct drm_i915_private *i915,
> +		 const struct i915_gem_proto_context *pc)
>  {
>  	struct i915_gem_context *ctx;
>  	struct i915_gem_engines *e;
> @@ -673,7 +763,7 @@ __create_context(struct drm_i915_private *i915)
>  
>  	kref_init(&ctx->ref);
>  	ctx->i915 = i915;
> -	ctx->sched.priority = I915_PRIORITY_NORMAL;
> +	ctx->sched = pc->sched;
>  	mutex_init(&ctx->mutex);
>  	INIT_LIST_HEAD(&ctx->link);
>  
> @@ -696,9 +786,7 @@ __create_context(struct drm_i915_private *i915)
>  	 * is no remap info, it will be a NOP. */
>  	ctx->remap_slice = ALL_L3_SLICES(i915);
>  
> -	i915_gem_context_set_bannable(ctx);
> -	i915_gem_context_set_recoverable(ctx);
> -	__context_set_persistence(ctx, true /* cgroup hook? */);
> +	ctx->user_flags = pc->user_flags;
>  
>  	for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
>  		ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
> @@ -786,38 +874,23 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
>  }
>  
>  static struct i915_gem_context *
> -i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
> +i915_gem_create_context(struct drm_i915_private *i915,
> +			const struct i915_gem_proto_context *pc)
>  {
>  	struct i915_gem_context *ctx;
>  	int ret;
>  
> -	if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
> -	    !HAS_EXECLISTS(i915))
> -		return ERR_PTR(-EINVAL);
> -
> -	ctx = __create_context(i915);
> +	ctx = __create_context(i915, pc);
>  	if (IS_ERR(ctx))
>  		return ctx;
>  
> -	if (HAS_FULL_PPGTT(i915)) {
> -		struct i915_ppgtt *ppgtt;
> -
> -		ppgtt = i915_ppgtt_create(&i915->gt);
> -		if (IS_ERR(ppgtt)) {
> -			drm_dbg(&i915->drm, "PPGTT setup failed (%ld)\n",
> -				PTR_ERR(ppgtt));
> -			context_close(ctx);
> -			return ERR_CAST(ppgtt);
> -		}
> -
> +	if (pc->vm) {
>  		mutex_lock(&ctx->mutex);

I guess this dies later, but this mutex_lock here is superflous since
right now no one else can get at our ctx struct. And nothing in
__assign_ppgtt checks for us holding the lock.

But fine if it only gets remove in the vm immutable patch.

> -		__assign_ppgtt(ctx, &ppgtt->vm);
> +		__assign_ppgtt(ctx, pc->vm);
>  		mutex_unlock(&ctx->mutex);
> -
> -		i915_vm_put(&ppgtt->vm);
>  	}
>  
> -	if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
> +	if (pc->single_timeline) {
>  		ret = drm_syncobj_create(&ctx->syncobj,
>  					 DRM_SYNCOBJ_CREATE_SIGNALED,
>  					 NULL);
> @@ -883,6 +956,7 @@ int i915_gem_context_open(struct drm_i915_private *i915,
>  			  struct drm_file *file)
>  {
>  	struct drm_i915_file_private *file_priv = file->driver_priv;
> +	struct i915_gem_proto_context *pc;
>  	struct i915_gem_context *ctx;
>  	int err;
>  	u32 id;
> @@ -892,7 +966,14 @@ int i915_gem_context_open(struct drm_i915_private *i915,
>  	/* 0 reserved for invalid/unassigned ppgtt */
>  	xa_init_flags(&file_priv->vm_xa, XA_FLAGS_ALLOC1);
>  
> -	ctx = i915_gem_create_context(i915, 0);
> +	pc = proto_context_create(i915, 0);
> +	if (IS_ERR(pc)) {
> +		err = PTR_ERR(pc);
> +		goto err;
> +	}
> +
> +	ctx = i915_gem_create_context(i915, pc);
> +	proto_context_close(pc);
>  	if (IS_ERR(ctx)) {
>  		err = PTR_ERR(ctx);
>  		goto err;
> @@ -1884,6 +1965,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
>  {
>  	struct drm_i915_private *i915 = to_i915(dev);
>  	struct drm_i915_gem_context_create_ext *args = data;
> +	struct i915_gem_proto_context *pc;
>  	struct create_ext ext_data;
>  	int ret;
>  	u32 id;
> @@ -1906,7 +1988,12 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
>  		return -EIO;
>  	}
>  
> -	ext_data.ctx = i915_gem_create_context(i915, args->flags);
> +	pc = proto_context_create(i915, args->flags);
> +	if (IS_ERR(pc))
> +		return PTR_ERR(pc);
> +
> +	ext_data.ctx = i915_gem_create_context(i915, pc);
> +	proto_context_close(pc);
>  	if (IS_ERR(ext_data.ctx))
>  		return PTR_ERR(ext_data.ctx);
>  
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index df76767f0c41b..a42c429f94577 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -46,6 +46,27 @@ struct i915_gem_engines_iter {
>  	const struct i915_gem_engines *engines;
>  };
>  
> +/**
> + * struct i915_gem_proto_context - prototype context
> + *
> + * The struct i915_gem_proto_context represents the creation parameters for
> + * an i915_gem_context.  This is used to gather parameters provided either
> + * through creation flags or via SET_CONTEXT_PARAM so that, when we create
> + * the final i915_gem_context, those parameters can be immutable.

The patch that puts them on an xa should explain how the locking here
works, even if it's rather trivial.

> + */
> +struct i915_gem_proto_context {
> +	/** @vm: See i915_gem_context::vm */
> +	struct i915_address_space *vm;
> +
> +	/** @user_flags: See i915_gem_context::user_flags */
> +	unsigned long user_flags;
> +
> +	/** @sched: See i915_gem_context::sched */
> +	struct i915_sched_attr sched;
> +

To avoid the kerneldoc warning point at your emulated syncobj here.

Also this file isn't included in the i915 context docs (why would it, the
docs have been left dead for years after all :-/). Please fix that in a
prep patch.

> +	bool single_timeline;
> +};
> +
>  /**
>   * struct i915_gem_context - client state
>   *
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> index 51b5a3421b400..e0f512ef7f3c6 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> @@ -80,11 +80,17 @@ void mock_init_contexts(struct drm_i915_private *i915)
>  struct i915_gem_context *
>  live_context(struct drm_i915_private *i915, struct file *file)
>  {
> +	struct i915_gem_proto_context *pc;
>  	struct i915_gem_context *ctx;
>  	int err;
>  	u32 id;
>  
> -	ctx = i915_gem_create_context(i915, 0);
> +	pc = proto_context_create(i915, 0);
> +	if (IS_ERR(pc))
> +		return ERR_CAST(pc);
> +
> +	ctx = i915_gem_create_context(i915, pc);
> +	proto_context_close(pc);
>  	if (IS_ERR(ctx))
>  		return ctx;
>  
> @@ -142,8 +148,14 @@ struct i915_gem_context *
>  kernel_context(struct drm_i915_private *i915)
>  {
>  	struct i915_gem_context *ctx;
> +	struct i915_gem_proto_context *pc;
> +
> +	pc = proto_context_create(i915, 0);
> +	if (IS_ERR(pc))
> +		return ERR_CAST(pc);
>  
> -	ctx = i915_gem_create_context(i915, 0);
> +	ctx = i915_gem_create_context(i915, pc);
> +	proto_context_close(pc);
>  	if (IS_ERR(ctx))
>  		return ctx;

With all comments addressed: Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2021-04-29 13:03 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-23 22:31 [PATCH 00/21] drm/i915/gem: ioctl clean-ups Jason Ekstrand
2021-04-23 22:31 ` [PATCH 01/21] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE Jason Ekstrand
2021-04-27  9:32   ` Daniel Vetter
2021-04-28  3:33     ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 02/21] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP Jason Ekstrand
2021-04-27  9:38   ` [Intel-gfx] " Daniel Vetter
2021-04-23 22:31 ` [PATCH 03/21] drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem Jason Ekstrand
2021-04-27  9:42   ` Daniel Vetter
2021-04-28 15:55   ` [Intel-gfx] " Tvrtko Ursulin
2021-04-28 17:24     ` Jason Ekstrand
2021-04-29  8:04       ` Tvrtko Ursulin
2021-04-29 14:54         ` Jason Ekstrand
2021-04-29 17:12           ` Daniel Vetter
2021-04-29 17:13             ` Daniel Vetter
2021-04-29 18:41               ` Jason Ekstrand
2021-04-30 11:18           ` Tvrtko Ursulin
2021-04-30 15:35             ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 04/21] drm/i915/gem: Return void from context_apply_all Jason Ekstrand
2021-04-27  9:42   ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 05/21] drm/i915: Drop the CONTEXT_CLONE API Jason Ekstrand
2021-04-27  9:49   ` [Intel-gfx] " Daniel Vetter
2021-04-28 17:38     ` Jason Ekstrand
2021-04-28 15:59   ` Tvrtko Ursulin
2021-04-23 22:31 ` [PATCH 06/21] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v3) Jason Ekstrand
2021-04-27  9:55   ` [Intel-gfx] " Daniel Vetter
2021-04-28 15:49   ` Tvrtko Ursulin
2021-04-28 17:26     ` Jason Ekstrand
2021-04-29  8:06       ` Tvrtko Ursulin
2021-04-29 12:08         ` Daniel Vetter
2021-04-29 14:47           ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 07/21] drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES Jason Ekstrand
2021-04-27  9:58   ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 08/21] drm/i915/gem: Disallow bonding of virtual engines Jason Ekstrand
2021-04-26 23:43   ` [PATCH 08/20] drm/i915/gem: Disallow bonding of virtual engines (v2) Jason Ekstrand
2021-04-27 13:58     ` [Intel-gfx] " Daniel Vetter
2021-04-27 13:51   ` [PATCH 08/21] drm/i915/gem: Disallow bonding of virtual engines Jason Ekstrand
2021-04-28 10:13     ` Daniel Vetter
2021-04-28 17:18       ` Jason Ekstrand
2021-04-28 17:18         ` [Intel-gfx] " Matthew Brost
2021-04-28 17:46           ` Jason Ekstrand
2021-04-28 17:55             ` Matthew Brost
2021-04-28 18:17               ` Jason Ekstrand
2021-04-29 12:14                 ` Daniel Vetter
2021-04-30  4:03                   ` Matthew Brost
2021-04-30 10:11                     ` Daniel Vetter
2021-05-01 17:17                       ` Matthew Brost
2021-05-04  7:36                         ` Daniel Vetter
2021-04-28 18:58         ` Jason Ekstrand
2021-04-29 12:16           ` Daniel Vetter
2021-04-29 16:02             ` Jason Ekstrand
2021-04-29 17:14               ` Daniel Vetter
2021-04-28 15:51   ` [Intel-gfx] " Tvrtko Ursulin
2021-04-29 12:24     ` Daniel Vetter
2021-04-29 12:54       ` Tvrtko Ursulin
2021-04-29 15:41         ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 09/21] drm/i915/gem: Disallow creating contexts with too many engines Jason Ekstrand
2021-04-28 10:16   ` [Intel-gfx] " Daniel Vetter
2021-04-28 10:42     ` Tvrtko Ursulin
2021-04-28 14:02       ` Daniel Vetter
2021-04-28 14:26         ` Tvrtko Ursulin
2021-04-28 17:09           ` Jason Ekstrand
2021-04-29  8:01             ` Tvrtko Ursulin
2021-04-29 19:16               ` Jason Ekstrand
2021-04-30 11:40                 ` Tvrtko Ursulin
2021-04-30 15:54                   ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 10/21] drm/i915/request: Remove the hook from await_execution Jason Ekstrand
2021-04-26 23:44   ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 11/21] drm/i915: Stop manually RCU banging in reset_stats_ioctl Jason Ekstrand
2021-04-28 10:27   ` Daniel Vetter
2021-04-28 18:22     ` Jason Ekstrand
2021-04-29 12:22       ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 12/21] drm/i915/gem: Add a separate validate_priority helper Jason Ekstrand
2021-04-28 14:37   ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 13/21] drm/i915/gem: Add an intermediate proto_context struct Jason Ekstrand
2021-04-29 13:02   ` Daniel Vetter [this message]
2021-04-29 16:44     ` [Intel-gfx] " Jason Ekstrand
2021-04-23 22:31 ` [PATCH 14/21] drm/i915/gem: Return an error ptr from context_lookup Jason Ekstrand
2021-04-29 13:27   ` [Intel-gfx] " Daniel Vetter
2021-04-29 15:29     ` Jason Ekstrand
2021-04-29 17:16       ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 15/21] drm/i915/gt: Drop i915_address_space::file Jason Ekstrand
2021-04-29 12:37   ` Daniel Vetter
2021-04-29 15:26     ` Jason Ekstrand
2021-04-23 22:31 ` [PATCH 16/21] drm/i915/gem: Delay context creation Jason Ekstrand
2021-04-24  3:21   ` [Intel-gfx] " kernel test robot
2021-04-24  3:24   ` kernel test robot
2021-04-29 15:51   ` Daniel Vetter
2021-04-29 18:16     ` Jason Ekstrand
2021-04-29 18:56       ` Daniel Vetter
2021-04-29 19:01         ` Jason Ekstrand
2021-04-29 19:07           ` Daniel Vetter
2021-04-29 21:35             ` Jason Ekstrand
2021-04-30  6:53               ` Daniel Vetter
2021-04-30 11:58                 ` Tvrtko Ursulin
2021-04-30 12:30                   ` Daniel Vetter
2021-04-30 12:44                     ` Tvrtko Ursulin
2021-04-30 13:07                       ` Daniel Vetter
2021-04-30 13:15                         ` Tvrtko Ursulin
2021-04-30 16:27                 ` Jason Ekstrand
2021-04-30 16:33                   ` Daniel Vetter
2021-04-30 16:57                     ` Jason Ekstrand
2021-04-30 17:08                       ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 17/21] drm/i915/gem: Don't allow changing the VM on running contexts Jason Ekstrand
2021-04-23 22:31 ` [PATCH 18/21] drm/i915/gem: Don't allow changing the engine set " Jason Ekstrand
2021-04-29 17:21   ` Daniel Vetter
2021-04-23 22:31 ` [PATCH 19/21] drm/i915/selftests: Take a VM in kernel_context() Jason Ekstrand
2021-04-23 22:31 ` [PATCH 20/21] i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec Jason Ekstrand
2021-04-29 17:19   ` [Intel-gfx] " Daniel Vetter
2021-04-23 22:31 ` [PATCH 21/21] drm/i915/gem: Roll all of context creation together Jason Ekstrand
2021-04-29 17:25   ` Daniel Vetter

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=YIqufo0AsyRndhav@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    /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;
as well as URLs for NNTP newsgroup(s).