dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jason Ekstrand <jason@jlekstrand.net>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 08/21] drm/i915/gem: Disallow bonding of virtual engines
Date: Thu, 29 Apr 2021 10:41:47 -0500	[thread overview]
Message-ID: <CAOFGe94gnnD7KyR00frfPs9BezaYK1OS5-kFJZzPzZWmbNdUoQ@mail.gmail.com> (raw)
In-Reply-To: <9681e7cc-b56e-f894-6384-85a23f47b4aa@linux.intel.com>

On Thu, Apr 29, 2021 at 7:54 AM Tvrtko Ursulin
<tvrtko.ursulin@linux.intel.com> wrote:
>
>
> On 29/04/2021 13:24, Daniel Vetter wrote:
> > On Wed, Apr 28, 2021 at 04:51:19PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 23/04/2021 23:31, Jason Ekstrand wrote:
> >>> This adds a bunch of complexity which the media driver has never
> >>> actually used.  The media driver does technically bond a balanced engine
> >>> to another engine but the balanced engine only has one engine in the
> >>> sibling set.  This doesn't actually result in a virtual engine.
> >>
> >> For historical reference, this is not because uapi was over-engineered but
> >> because certain SKUs never materialized.
> >
> > Jason said that for SKU with lots of media engines media-driver sets up a
> > set of ctx in userspace with all the pairings (and I guess then load
> > balances in userspace or something like that). Tony Ye also seems to have
> > confirmed that. So I'm not clear on which SKU this is?
>
> Not sure if I should disclose it here. But anyway, platform which is
> currently in upstream and was supposed to be the first to use this uapi
> was supposed to have at least 4 vcs engines initially, or even 8 vcs + 4
> vecs at some point. That was the requirement uapi was designed for. For
> that kind of platform there were supposed to be two virtual engines
> created, with bonding, for instance parent = [vcs0, vcs2], child =
> [vcs1, vcs3]; bonds = [vcs0 - vcs1, vcs2 - vcs3]. With more engines the
> merrier.

I've added the following to the commit message:

    This functionality was originally added to handle cases where we may
    have more than two video engines and media might want to load-balance
    their bonded submits by, for instance, submitting to a balanced vcs0-1
    as the primary and then vcs2-3 as the secondary.  However, no such
    hardware has shipped thus far and, if we ever want to enable such
    use-cases in the future, we'll use the up-and-coming parallel submit API
    which targets GuC submission.

--Jason

> Userspace load balancing, from memory, came into the picture only as a
> consequence of balancing between two types of media pipelines which was
> either working around the rcs contention or lack of sfc, or both. Along
> the lines of - one stage of a media pipeline can be done either as GPGPU
> work, or on the media engine, and so userspace was deciding to spawn "a
> bit of these and a bit of those" to utilise all the GPU blocks. Not
> really about frame split virtual engines and bonding, but completely
> different load balancing, between gpgpu and fixed pipeline.

> > Or maybe the real deal is only future platforms, and there we have GuC
> > scheduler backend.
>
> Yes, because SKUs never materialised.
>
> > Not against adding a bit more context to the commit message, but we need
> > to make sure what we put there is actually correct. Maybe best to ask
> > Tony/Carl as part of getting an ack from them.
>
> I think there is no need - fact uapi was designed for way more engines
> than we got to have is straight forward enough.
>
> Only unasked for flexibility in the uapi was the fact bonding can
> express any dependency and not only N consecutive engines as media fixed
> function needed at the time. I say "at the time" because in fact the
> "consecutive" engines requirement also got more complicated / broken in
> a following gen (via fusing and logical instance remapping), proving the
> point having the uapi disassociated from the hw limitations of the _day_
> was a good call.
>
> Regards,
>
> Tvrtko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2021-04-29 15:42 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 [this message]
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   ` [Intel-gfx] " Daniel Vetter
2021-04-29 16:44     ` 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=CAOFGe94gnnD7KyR00frfPs9BezaYK1OS5-kFJZzPzZWmbNdUoQ@mail.gmail.com \
    --to=jason@jlekstrand.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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).