Re: [RFC PATCH] drm/panfrost: Add initial panfrost driver

From: Alyssa Rosenzweig <alyssa@rosenzweig.io>
To: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	David Airlie <airlied@linux.ie>,
	"Marty E. Plummer" <hanetzer@startmail.com>,
	Sean Paul <sean@poorly.run>
Subject: Re: [RFC PATCH] drm/panfrost: Add initial panfrost driver
Date: Fri, 8 Mar 2019 10:46:02 -0800	[thread overview]
Message-ID: <20190308184602.GB1607@kevin> (raw)
In-Reply-To: <CAL_JsqKQAqbGO4xO96u7u1LQAFt=b_T5oBtJcPbyTgqiGVpPfg@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 1814 bytes --]

> 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:
> 
> https://www.notebookcheck.net/Samsung-Chromebook-XE303C12-A01US.84022.0.html
> 
> 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...
> 
> 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! :)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel