From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alyssa Rosenzweig Subject: Re: [RFC PATCH] drm/panfrost: Add initial panfrost driver Date: Fri, 8 Mar 2019 10:46:02 -0800 Message-ID: <20190308184602.GB1607@kevin> References: <20190308002408.32682-1-robh@kernel.org> <20190308050041.GC10814@rosenzweig.io> <20190308153456.GA16073@rosenzweig.io> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0125489414==" Return-path: Received: from rosenzweig.io (rosenzweig.io [107.170.207.86]) by gabe.freedesktop.org (Postfix) with ESMTPS id DDECF6E3A8 for ; Fri, 8 Mar 2019 18:46:04 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Herring Cc: Tomeu Vizoso , Maxime Ripard , dri-devel , David Airlie , "Marty E. Plummer" , Sean Paul List-Id: dri-devel@lists.freedesktop.org --===============0125489414== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > It was given to me and a bunch of other ARM kernel devs, but I think > it was in production by then. It's an A01 rev which matches this: >=20 > https://www.notebookcheck.net/Samsung-Chromebook-XE303C12-A01US.84022.0.h= tml >=20 > The only other rev is a UK version. Wacky. Something seems decidedly odd about a "-dev" GPU used in production, though I concede snow was an odd machine in the first place. > Core affinity. It's which shader cores to use which was based on flags > you pass in for the job. Some of the h/w has multiple L2 caches (IIRC > just bifrost) and the code is fairly hard to follow which is why it's > just hardcoded. Sorry, I don't have a better explanation, but I've > already forgotten some of the details and stopped looking at it once I > found hardcoding it would work for now... >=20 > This and other parts of this code is why I asked if there are other > features of the kbase job submit that we may need in the future > (besides just compute). Ahh, okay. As far as I can tell, what we have now (plus the basic compute adjustments we've talked about) should be good through GLES3. It's possible the hairier details are maybe exposed in OpenCL (?), but I haven't looked at that yet, so I couldn't say. It's probably fine to keep hardcoding until we can't. > I understand, but wouldn't just running conformance tests likely kill > things too? I'm guessing we can't even run a web browser yet, so WebGL > problem is solved. ;) Hehe, yes, the conformance tests definitely cause everything to go kerplutz, hence why having resetting is essential just from a stability standpoint (even just for dev, let alone security issues -- unlikely most of the above, this *is* a blocker IMO). > In any case, Tomeu said resetting is next up for him. Ah, good! :) --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEQ17gm7CvANAdqvY4/v5QWgr1WA0FAlyCuGoACgkQ/v5QWgr1 WA0gYA/+JCRuiOLN8eZ9IqJbJowv6PCYj4kjM30AL4Gs6mXX+WFTWiVOGoPczolA Xo8E3AayC4UZUXe2ScDWw+w+DCMaH3nzLUDrQqsvZ8/uz42GTASVwoVYl0Yfg9ER IALV7HObS05130xLd8zdgJdXtnNHYiRlfSMGCuu9vqydOPH1fKTuPo1hpkMLGU14 3dDpTo1sUYW656gGovq1IgveDmXKqEizl46+wMT+h3TMx2q7zMaa95JP/VQyH/LM XXz8dLCs3CpSQJj4LKY8QVLRW5A1BFyGOfHGaEQLI8dVfK+KbICrctVe287n2Mcj zuD/E3rFCy3iphp2UXKCoNaMqoC0OxG7chzVco97XDLzFiBbKdnrntP6Yg/HNJ+X A7hW/rFBsNnZXhERdTdAbZtDiy/b7IqLyPxvnoZFwUuZKfVNaSPuCkbBUvoke54U LqqitPtrMcVyYE9cfbgRnBe94jRgZ2CUM2/PbKK6VbTPCU/+mvQZfCvi5OMwTs4D MWpbNTzJ5n6ZLtupRQbqvsNQ5+6pGe+r0FTpfb4hzNDxeRlUxyd84tGEPNfFXcGG 58//1+ayScNxOC2TDbtL2yhY5ElgOKFymQmF6sNZhy2RZ5t6RrA2Xsc+MFClS31s QxUd6SbTuIa3SIG4qnr9TTtdXIkCUcB5E9G9/eo6M5efuEmfNlc= =VBbu -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH-- --===============0125489414== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============0125489414==--