From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup
Date: Fri, 27 Aug 2021 15:44:42 +0100 [thread overview]
Message-ID: <9c042851-9a27-6bc7-0749-ed0c573e9c80@linux.intel.com> (raw)
In-Reply-To: <20210827143941.287958-1-tvrtko.ursulin@linux.intel.com>
On 27/08/2021 15:39, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
> when rendering is done on Intel dgfx and scanout/composition on Intel
> igfx.
>
> Before this patch the driver was not quite ready for that setup, mainly
> because it was able to emit a semaphore wait between the two GPUs, which
> results in deadlocks because semaphore target location in HWSP is neither
> shared between the two, nor mapped in both GGTT spaces.
>
> To fix it the patch adds an additional check to a couple of relevant code
> paths in order to prevent using semaphores for inter-engine
> synchronisation between different driver instances.
>
> Patch also moves singly used i915_gem_object_last_write_engine to be
> private in its only calling unit (debugfs), while modifying it to only
> show activity belonging to the respective driver instance.
>
> What remains in this problem space is the question of the GEM busy ioctl.
> We have a somewhat ambigous comment there saying only status of native
> fences will be reported, which could be interpreted as either i915, or
> native to the drm fd. For now I have decided to leave that as is, meaning
> any i915 instance activity continues to be reported.
>
> v2:
> * Avoid adding rq->i915. (Chris)
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 17 ----------
> drivers/gpu/drm/i915/i915_debugfs.c | 39 ++++++++++++++++++++--
> drivers/gpu/drm/i915/i915_request.c | 12 ++++++-
> 3 files changed, 47 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 48112b9d76df..3043fcbd31bd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -503,23 +503,6 @@ i915_gem_object_finish_access(struct drm_i915_gem_object *obj)
> i915_gem_object_unpin_pages(obj);
> }
>
> -static inline struct intel_engine_cs *
> -i915_gem_object_last_write_engine(struct drm_i915_gem_object *obj)
> -{
> - struct intel_engine_cs *engine = NULL;
> - struct dma_fence *fence;
> -
> - rcu_read_lock();
> - fence = dma_resv_get_excl_unlocked(obj->base.resv);
> - rcu_read_unlock();
> -
> - if (fence && dma_fence_is_i915(fence) && !dma_fence_is_signaled(fence))
> - engine = to_request(fence)->engine;
> - dma_fence_put(fence);
> -
> - return engine;
> -}
> -
> void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
> unsigned int cache_level);
> void i915_gem_object_flush_if_display(struct drm_i915_gem_object *obj);
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index 04351a851586..55fd6191eb32 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -135,13 +135,46 @@ static const char *stringify_vma_type(const struct i915_vma *vma)
> return "ppgtt";
> }
>
> +static char *
> +last_write_engine(struct drm_i915_private *i915,
> + struct drm_i915_gem_object *obj)
> +{
> + struct intel_engine_cs *engine;
> + struct dma_fence *fence;
> + char *res = NULL;
> +
> + rcu_read_lock();
> + fence = dma_resv_get_excl_unlocked(obj->base.resv);
> + rcu_read_unlock();
> +
> + if (!fence || dma_fence_is_signaled(fence))
> + goto out;
> +
> + if (!dma_fence_is_i915(fence)) {
> + res = "<external-fence>";
> + goto out;
> + }
> +
> + engine = to_request(fence)->engine;
> + if (engine->gt->i915 != i915) {
> + res = "<external-i915>";
> + goto out;
> + }
> +
> + res = engine->name;
> +
> +out:
> + dma_fence_put(fence);
> + return res;
> +}
> +
> void
> i915_debugfs_describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
> {
> struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> - struct intel_engine_cs *engine;
> struct i915_vma *vma;
> int pin_count = 0;
> + char *engine;
>
> seq_printf(m, "%pK: %c%c%c %8zdKiB %02x %02x %s%s%s",
> &obj->base,
> @@ -230,9 +263,9 @@ i915_debugfs_describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
> if (i915_gem_object_is_framebuffer(obj))
> seq_printf(m, " (fb)");
>
> - engine = i915_gem_object_last_write_engine(obj);
> + engine = last_write_engine(dev_priv, obj);
> if (engine)
> - seq_printf(m, " (%s)", engine->name);
> + seq_printf(m, " (%s)", engine);
Or I zap this from the code altogether. Not sure it is very useful since
the only caller is i915_gem_framebuffer debugfs file and how much it can
care about maybe hitting the timing window when exclusive fence will
contain something.
Regards,
Tvrtko
> }
>
> static int i915_gem_object_info(struct seq_file *m, void *data)
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index ce446716d092..64adf619fe82 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1152,6 +1152,12 @@ __emit_semaphore_wait(struct i915_request *to,
> return 0;
> }
>
> +static bool
> +can_use_semaphore_wait(struct i915_request *to, struct i915_request *from)
> +{
> + return to->engine->gt == from->engine->gt;
> +}
> +
> static int
> emit_semaphore_wait(struct i915_request *to,
> struct i915_request *from,
> @@ -1160,6 +1166,9 @@ emit_semaphore_wait(struct i915_request *to,
> const intel_engine_mask_t mask = READ_ONCE(from->engine)->mask;
> struct i915_sw_fence *wait = &to->submit;
>
> + if (!can_use_semaphore_wait(to, from))
> + goto await_fence;
> +
> if (!intel_context_use_semaphores(to->context))
> goto await_fence;
>
> @@ -1263,7 +1272,8 @@ __i915_request_await_execution(struct i915_request *to,
> * immediate execution, and so we must wait until it reaches the
> * active slot.
> */
> - if (intel_engine_has_semaphores(to->engine) &&
> + if (can_use_semaphore_wait(to, from) &&
> + intel_engine_has_semaphores(to->engine) &&
> !i915_request_has_initial_breadcrumb(to)) {
> err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
> if (err < 0)
>
next prev parent reply other threads:[~2021-08-27 14:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-27 13:30 [PATCH] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup Tvrtko Ursulin
2021-08-27 14:39 ` [PATCH v2] " Tvrtko Ursulin
2021-08-27 14:44 ` Tvrtko Ursulin [this message]
2021-08-30 8:26 ` [Intel-gfx] " Daniel Vetter
2021-08-31 9:15 ` Tvrtko Ursulin
2021-08-31 12:43 ` Daniel Vetter
2021-08-31 13:18 ` Tvrtko Ursulin
2021-09-02 14:33 ` Daniel Vetter
2021-09-02 15:01 ` Tvrtko Ursulin
2021-09-08 17:06 ` Daniel Vetter
2021-09-09 8:26 ` Tvrtko Ursulin
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=9c042851-9a27-6bc7-0749-ed0c573e9c80@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=tvrtko.ursulin@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;
as well as URLs for NNTP newsgroup(s).