Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Eric Anholt <eric@anholt.net>
To:     dri-devel@lists.freedesktop.org
Cc:     linux-kernel@vger.kernel.org,
        Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
        Maxime Ripard <maxime.ripard@bootlin.com>,
        david.emett@broadcom.com, thomas.spurden@broadcom.com
Subject: Re: [PATCH v2 3/5] drm/v3d: Add support for compute shader dispatch.
In-Reply-To: <20190416225856.20264-4-eric@anholt.net>
References: <20190416225856.20264-1-eric@anholt.net> <20190416225856.20264-4-eric@anholt.net>
User-Agent: Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/26.1 (x86_64-pc-linux-gnu)
Date:   Wed, 17 Apr 2019 14:53:33 -0700
Message-ID: <87v9zc1eoy.fsf@anholt.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha512; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--=-=-=
Content-Type: text/plain

Eric Anholt <eric@anholt.net> 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-----
--=-=-=--