4 ms·
Great presentation..one of the major issues with the support of RK3588 is that the GPU doesn't have proper drivers, so GPU acceleration relies on patches made b
by madduci 3y ago
Great presentation..one of the major issues with the support of RK3588 is that the GPU doesn't have proper drivers, so GPU acceleration relies on patches made by small contributors and these are obviously not updated regularly, so they tend to be obsolete easily.
- not_your_vase 3y agoA story as old as the embedded ARM ecosystem itself :(
- jsheard 3y agoAMD is probably the best hope nowadays, they've started licensing their RDNA GPU architecture out to ARM SOC vendors and they already have excellent open source drivers. Mali and Adreno are still much more common though, especially on cheap SBCs which nearly always use Mali.
- my123 3y agoI hoped so but nope. Exynos with RDNA has closed source user-space, with AMD/Samsung not making public the differences, and no attempt at upstreaming the kernel-side ones too. The best mobile platform on Arm with open-source GPU drivers rn is Qualcomm...
- mort96 3y agoEither that, or using the proprietary Mali drivers which rely on userspace X11 GPU drivers which don't work in current versions of X or current kernels so you end up running 5.10 using a separate x11-legacy package. ARM GPUs on Linux are truly in a terrible state right now. I hope ARM gets serious about ensuring that upstream supports their GPUs soon after release.
- snvzz 3y ago>I hope ARM gets serious about ensuring that upstream supports their GPUs soon after release. Ironically, Imagination Technologies of PowerVR fame (infamy?) did, with a funded mesa3d driver effort. And embraced RISC-V while at it.
- zokier 3y agoAt least ARM is not completely antagonist anymore and is actually funding some this effort, that is already pretty good step forwards. But yes, there is long way to go for everyone here. https://newsroom.arm.com/news/arm-expands-open-source-partnerships https://newsroom.arm.com/news/arm-expands-open-source-partne...
- mort96 3y agoI've seen that too, I'm (very) cautiously optimistic. Ideally, ARM would be doing a bunch of the development work and actually ensure that the driver support is ready to be upstreamed on day 1 (like what AMD pretty much does AFAIU). However, the Mali-G610 (used in the RK3588) is still not supported despite being released in 2021. ARM's "work with Collabora" started before the release of the Mali-G610, so the fact that we're so far from upstream support even after this many years of development seems like a bad sign. I don't understand why future Mali architectures wouldn't also take 4+ years unless ARM really really steps it up.
- throw354279 3y ago> I don't understand why future Mali architectures wouldn't also take 4+ years unless ARM really really steps it up. G610 (and the larger G710) are sort of special since there was a major change to the internal architecture and how work is submitted to the GPUs. Later versions didn't have such a big, breaking change.
- zokier 3y agoThe situation doesn't seem quite so dire, Collabora is apparently working on driver for this now: https://www.phoronix.com/news/Panthor-DRM-Newer-Mali https://www.phoronix.com/news/Panthor-DRM-Newer-Mali They have pretty decent track record in producing these sort of drivers so there is a chance
- mntmn 3y agoThis is not true, the panthor driver (previously pancsf) for mesa is actively being developed and funded, and already works quite well (I had a demo desktop running on prototye MNT Reform Next laptop at 37c3).
- mort96 3y agoI feel like "already" is a bit strong considering the GPU has been out for almost 3 years and it's still seemingly far from upstream.
- imtringued 3y agoAnd the main panfrost developer Alyssa Rosenzweig has moved on, so the pace of development has declined significantly. At this point the Raspberry Pi 5 is more than capable and the Rock 5 has lost the primary advantage it once had.
- fooishbar 3y agoIt's nothing to do with that really. It's much more to do with the gen10 (Gxxx) Mali requiring a completely new kernel driver. Given that nouveau and other drivers required the same thing, this ended up being a long diversion into a lot of new common DRM infrastructure to make things easier for the next drivers who need to do the same thing. By comparison, enabling gen9 in the kernel was more like adding a couple of device IDs. See bbrezillon & dakr's talk here for more details: https://indico.freedesktop.org/event/4/contributions/181/ https://indico.freedesktop.org/event/4/contributions/181/