From: Kenneth Graunke <kenneth@whitecape.org>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
Date: Tue, 08 Jan 2019 12:32:05 -0800 [thread overview]
Message-ID: <20368564.BWzELJ56SV@kirito> (raw)
In-Reply-To: <154696278569.12236.2076663454164859731@jlahtine-desk.ger.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 2390 bytes --]
On Tuesday, January 8, 2019 7:53:05 AM PST Joonas Lahtinen wrote:
> + Ken/Jason for Mesa
> Quoting Matt Roper (2019-01-07 21:19:31)
> > On Mon, Jan 07, 2019 at 01:23:50PM +0100, Michał Winiarski wrote:
> > > On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> > > > Quoting José Roberto de Souza (2019-01-04 19:37:00)
> > > > > According to Workaround database ICL also needs
> > > > > WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> > > > > fine-granularity preemptions per-context.
> > > >
> > > > I must wonder where is the userspace component that needs this, and why
> > > > it hasn't been noticed earlier?
> > > >
> > > > Or is this one more of the cases when no userspace actually uses the
> > > > register?
> > >
> > > It's used:
> > > https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/brw_state_upload.c#L64
> > >
> > > -Michał
> >
> > Wasn't this just an artificial i915-only workaround that was added to
> > prevent breakage of pre-preemption UMD's? Initial gen9 driver releases
> > didn't support preemption, so when preemption support did get added to
> > i915, the kernel had to force object-level off by default at context
> > creation to avoid breaking old userspace that didn't build batch buffers
> > with all the necessary preemption workarounds. This CS_CHICKEN1
> > register was then exposed to userspace so that newer, preemption-aware
> > userspace could opt back in if it properly supported preemption.
> >
> > For gen11, there shouldn't be any "old" userspace around that doesn't
> > support preemption, so shouldn't the kernel just leave object-level
> > preemption enabled by default (meaning there's no need to expose this
> > register to userspace to allow it to explicitly opt-in)?
>
> Makes sense to me. We should have known by know if somebody expects to
> control the register, because they would be failing to do so.
>
> Mesa could also drop the register load for Gen11+
>
> Regards, Joonas
+ Rafael, as he's done all the preemption work in Mesa.
That seems reasonable to me. It looks like i965 always enables
mid-object preemption (sets CS_CHICKEN1 bit 0) on Gen10+, and never
disables it. You can probably safely turn it on by default, and we
can stop writing the register altogether.
Thanks for the heads up!
--Ken
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-01-08 20:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-04 17:37 [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD José Roberto de Souza
2019-01-04 17:59 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-01-04 20:44 ` ✓ Fi.CI.IGT: " Patchwork
2019-01-07 11:01 ` [PATCH] " Joonas Lahtinen
2019-01-07 12:23 ` Michał Winiarski
2019-01-07 19:19 ` Matt Roper
2019-01-08 15:53 ` Joonas Lahtinen
2019-01-08 20:32 ` Kenneth Graunke [this message]
2019-01-16 0:29 ` Rafael Antognolli
2019-01-09 17:07 ` Michał Winiarski
2019-01-09 20:38 ` Sripada, Radhakrishna
2019-01-15 7:25 ` Joonas Lahtinen
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=20368564.BWzELJ56SV@kirito \
--to=kenneth@whitecape.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@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