All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenneth Graunke <kenneth@whitecape.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: mesa-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Subject: Re: [PATCH 2/3] iris: Create a composite context for both compute and render pipelines
Date: Mon, 25 Mar 2019 22:52:10 -0700	[thread overview]
Message-ID: <2324673.Bn3h3PiK9P@kirito> (raw)
In-Reply-To: <20190325105900.16346-2-chris@chris-wilson.co.uk>


[-- Attachment #1.1: Type: text/plain, Size: 2507 bytes --]

On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> iris currently uses two distinct GEM contexts to have distinct logical
> HW contexts for the compute and render pipelines. However, using two
> distinct GEM contexts implies that they are distinct timelines, yet as
> they are a single GL context that implies they belong to a single
> timeline from the client perspective. Currently, fences are occasionally
> inserted to order the two timelines. Using 2 GEM contexts, also implies
> that we keep 2 ppGTT for identical buffer state. If we can create a
> single GEM context, with the right capabilities, we can have a single
> VM, a single timeline, but 2 logical HW contexts for the 2 pipelines.
> 
> This is allowed through the new context interface that allows VM to be
> shared, timelines to be specified, and for the logical contexts to be
> constructed as the user desires.
> 
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Kenneth Graunke <kenneth@whitecape.org>
> ---
>  src/gallium/drivers/iris/iris_batch.c   | 16 ++-----
>  src/gallium/drivers/iris/iris_batch.h   |  5 +--
>  src/gallium/drivers/iris/iris_context.c | 56 ++++++++++++++++++++++++-
>  3 files changed, 60 insertions(+), 17 deletions(-)

Hi Chris,

I don't think that I want the single timeline option.  It seems like
we've been moving away from implicit sync for a long time, and the
explicit sync code we have is pretty straightforward and seems to do
the trick.  Jason and I also chatted briefly, and we don't necessarily
want to a strict submission-order between render/compute.

Separating the VMA from the context state image seems like absolutely
the right thing to do - as you said, they're separate in hardware,
and no real reason to tie it together.  I would be in favor of new
uABI for that.

I don't think there will be much overhead reduction from sharing the
VMA here though.  It's very plausible that the compositor might want
to run between render and compute batches, at which point we end up
doing page directory loads anyway.  I have also heard rumors about bit
47 becoming magical at some point which may prohibit us from sharing...

Context cloning seems OK, but I'm always pretty hesitant to add new
uABI unless it's strictly necessary.  In this case, we can do the same
thing with a little bit of userspace code, so I'm not sure it's worth
adding that...

I would love to see an iris patch to use the new
I915_CONTEXT_PARAM_RECOVERABLE option without the other dependencies.

--Ken

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

  reply	other threads:[~2019-03-26  5:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25 10:58 [PATCH 1/3] drm-uapi: Pull i915_drm.h changes for context cloning Chris Wilson
2019-03-25 10:58 ` [PATCH 2/3] iris: Create a composite context for both compute and render pipelines Chris Wilson
2019-03-26  5:52   ` Kenneth Graunke [this message]
2019-03-26  7:16     ` Chris Wilson
2019-03-26 17:01       ` Kenneth Graunke
2019-03-26 17:15         ` Chris Wilson
2019-03-31  9:57   ` [Intel-gfx] " Jordan Justen
2019-03-31 10:02     ` Chris Wilson
2019-03-31 10:41       ` Jordan Justen
2019-03-25 10:59 ` [PATCH 3/3] iris: Handle GPU recovery Chris Wilson
2019-03-31  9:53 ` [Mesa-dev] [PATCH 1/3] drm-uapi: Pull i915_drm.h changes for context cloning Jordan Justen
2019-03-31  9:55   ` 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=2324673.Bn3h3PiK9P@kirito \
    --to=kenneth@whitecape.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=mesa-dev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.