From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Re: [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD Date: Tue, 08 Jan 2019 12:32:05 -0800 Message-ID: <20368564.BWzELJ56SV@kirito> References: <20190104173700.26574-1-jose.souza@intel.com> <20190107191929.GA45@mdroper-MOBL.amr.corp.intel.com> <154696278569.12236.2076663454164859731@jlahtine-desk.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1370725799==" Return-path: Received: from smtp89.iad3b.emailsrvr.com (smtp89.iad3b.emailsrvr.com [146.20.161.89]) by gabe.freedesktop.org (Postfix) with ESMTPS id A115F6EBA3 for ; Tue, 8 Jan 2019 20:41:47 +0000 (UTC) In-Reply-To: <154696278569.12236.2076663454164859731@jlahtine-desk.ger.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Joonas Lahtinen Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1370725799== Content-Type: multipart/signed; boundary="nextPart5311446.YEdjdERB0k"; micalg="pgp-sha256"; protocol="application/pgp-signature" --nextPart5311446.YEdjdERB0k Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=C5=82 Winiarski wrote: > > > On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote: > > > > Quoting Jos=C3=A9 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. > > > >=20 > > > > I must wonder where is the userspace component that needs this, and= why > > > > it hasn't been noticed earlier? > > > >=20 > > > > Or is this one more of the cases when no userspace actually uses the > > > > register? > > >=20 > > > It's used: > > > https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers= /dri/i965/brw_state_upload.c#L64 > > >=20 > > > -Micha=C5=82 > >=20 > > 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. > >=20 > > 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)? >=20 > 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. >=20 > Mesa could also drop the register load for Gen11+ >=20 > 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! =2D-Ken --nextPart5311446.YEdjdERB0k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE6OtbNAgc4e6ibv4ZW1vaBx1JzDgFAlw1CMUACgkQW1vaBx1J zDjX1Q//axNa4YkT71NnQ2Uohp2cyOKln6gSjfhiHzdhDBcs/iqRx+tfls/GHZkK Nfu8Btwe4nfgNHx5ZZ7w6UuH+vOVcAowGQlzlU2cId5zD9gJReWRtnVOAIa8eySM q7OCtphhmZ6aKc/uZEGSXV4xtL/WgksQlq0iR9Z4nkU/y/yRPBEqE05PjgNkZEld jd4rqdajYzEZADlBfPY9tSBSXtdXXe6K52JjWkCFUUYX8v+ZVTdrxsjiq3VX3VIc HvWPjE4l/GczRfSJ8Mtt63lVAd0VZ3CFmK6IObLJkwmLDnNqHY+OMR79AA0Fbume QRA6dc5DzfL6m4SZPR8LURxTzsGZcWSfA8gldrL7Na7PBlUzVjRyvW2h8QGtEzbB BEa1XQAcUKQicVJamvlU5mPskx3hw+TAwu+gw0SZf0+RLOFoThiuyM0KmtBdsLdu r8VYcqfPXU42Ym5/YEnoc4WMGo4oT7I1USBy2+f3aeO2awXi2D2eeC1Fdf6E9vJm nJUTy16N4K1j2KDF4Z6i7TjtTKbAqczzZHUOry5tHPZk3w9CUqQ+5/6ToyKlpRZ5 wlyMiY50cGEk0WMkgPLrgPk67lXdGhm6VSOQXYYPxOeLFYB8q+CH/FGg2ETBE2Bd Ay2hRgNbdZ9jTrHf58Ul5Poc9e7F8h3JjDK55PUnARW2vaqbLik= =OtFb -----END PGP SIGNATURE----- --nextPart5311446.YEdjdERB0k-- --===============1370725799== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1370725799==--