From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH v2 3/5] drm/v3d: Add support for compute shader dispatch. Date: Wed, 17 Apr 2019 14:53:33 -0700 Message-ID: <87v9zc1eoy.fsf@anholt.net> References: <20190416225856.20264-1-eric@anholt.net> <20190416225856.20264-4-eric@anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1486498686==" Return-path: Received: from anholt.net (anholt.net [50.246.234.109]) by gabe.freedesktop.org (Postfix) with ESMTP id D0D6A6E0AC for ; Wed, 17 Apr 2019 21:53:35 +0000 (UTC) In-Reply-To: <20190416225856.20264-4-eric@anholt.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org Cc: Paul Kocialkowski , Maxime Ripard , david.emett@broadcom.com, thomas.spurden@broadcom.com, linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org --===============1486498686== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Eric Anholt writes: > The compute shader dispatch interface is pretty simple -- just pass in > the regs that userspace has passed us, with no CLs to run. However, > with no CL to run it means that we need to do manual cache flushing of > the L2 after the HW execution completes (for SSBO, atomic, and > image_load_store writes that are the output of compute shaders). > > This doesn't yet expose the L2 cache's ability to have a region of the > address space not write back to memory (which could be used for > shared_var storage). > > So far, the Mesa side has been tested on V3D v4.2 simpenrose (passing > the ES31 tests), and on the kernel side on 7278 (failing atomic > compswap tests in a way that doesn't reproduce on simpenrose). Fixed the compswap issue in Mesa. Looks like cmpxchg needed the TYPE field set to vec2 instead of 32-bit, since there are two values written to TMUD. The spec says the field is ignored, but that doesn't seem to be the case. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAly3oF0ACgkQtdYpNtH8 nuhmkw//W73RUmscXiZ3tiorQBErHuvZ+x0nAm8ZmNctGr0Z4+JqG/AvFTjFH7UM IQqjpXlBJTI3PRSWM130ezsLVfznbSQiJXUVwEsi+vBkW+ZzsaHArY+BwqDu/b2r 0WwrPYkyESZ0rm3J664vAuug0R7pnaC1/ePTxF3QZlDjmsqQQxV191MXRCj0YazI rd/3ALrqs6ZC3/7NQJRXgxUG0D0lABOsre7nkzjsjl7vlGaQlXMac1ttpfCiFe7k ebkzgwHsCuLFPq9Ll9rJ35LsqQTr7wWGKucveU8Q99VvWA2taYvog2Ei1IrFeWKQ ROTwvnqbTkugnQx2tzdbDvMcVLvsFaJw/u1rj6r/HOcnhc/ElGTpR4NeAztBtwu5 TvyTaDFJXhvZxygJB4oQiES6cw3Z7jBTkWTFZKKZifeVwmAdweO8iw6YSjoaEtW6 1ELfDvL98sGDxDFSFu2Gepk+ooa5fs8EiNE7wyNHwRD+icjwvVLOlOHwcX6OTjyd Hme05kpS/yuVTohaTekawmKxi7bQN8hxXX1nc8bRBaP4VkjmMA17Fxx/9On7JB2+ 4OMPpNWeJ++wiarDuSzkRnsD9xizT38MwuUhLAxdTL+bvsI4t0/jRLbkuad/i57h oFZrt3duCwZyrpqcuEfEDQgeNMvVsCJyrAp49s9VF6QSaEPU3Sw= =N+zs -----END PGP SIGNATURE----- --=-=-=-- --===============1486498686== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1486498686==--