> 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! :)
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
