Open source Mali GPU drivers merged
lkml.org
lkml.org
The message says there's two drivers:
"Lima covers the older t4xx and panfrost the newer 6xx/7xx series"
My perception is that Mali GPUs were just in Android phones where running where it's generally not possible to run a vanilla kernel or the bootloader is locked.
Any dev boards?
Basically this DRM driver plus the companion Panfrost Gallium3D driver merged into mesa 19.1 will enable blob-free 3D graphics on the C201 and other devices that use this chipset.
Right now the DRM kernel driver does not support X11, so it'll be a few more releases before I can really take advantage of it. I have successfully installed it along with and run the kmscube demo outside of X. Pretty exciting development.
With Panfrost, every component of the C201 except the BCM4354 WiFi chip becomes libre. Cypress bought out a division of Broadcom and started releasing datasheets on a bunch of WiFi chips including the BCM4354, which they now tag as CYW4354. (PDF: https://www.cypress.com/file/298141/download)
Not sure if that makes it easier or any more realistic to get blob-free firmware for this chip. I can only hope.
Now GPU acceleration will be achievable via open source.
You can run ARM based Linux distros on them (such as Armbian). Up to now, most people use the ARM proprietary blobs to get OpenGL ES acceleration working on those things.
However, my experience in the hardware industry leads me to believe it's something about an 'intellectual property' fetish and pearl-clutching when confronted with the idea of 'giving away code for free'.
e.g. when AMD open sourced AMDVLK, they had to replace the proprietary compiler it was depending on with LLVM. That was an easy one. Many projects are much more deeply intertwined with proprietary crap.
Their driver are not merely to "communicate" with the hardware. The driver include a lot of hotfix and optimization, sometimes specific to one game/application. The driver give them a competitive advantage over their competitor. They will probably never released it for free.
Interestingly, amdgpu/Mesa performance seems to be higher for typical game rendering than AMD's proprietary stack. I suspect at some point in the future AMD will abandon their 'pro' proprietary stack entirely after realizing they should stick to being a hardware business.
Now, with NVidia diving more and more into the ML / GPGPU market (which is less windows-focused), they might have more pressure to actually open-source their driver (or at least, finally make them actually integrated properly with Linux), at least for their server focused hardware. But I wouldn't bet on it any time soon.
Let's be honest, they have a dominant position on the market. And their driver, as awful as they are, work. I think a lot of things would have to change for them to have the incentive to open-source them. My only hope at this point is that, with the growing GPGPU market, they might finally start to see Linux not as a second-class citizen.
John Bridgman of AMD confirmed it's their plan like 5+ years ago. The only reason they ever maintained proprietary stack on Linux is workstation users who need certified OpenGL implementation for various proprietary software.
By now the only proprietary parts of "pro" stack are OpenGL implementation and shader compiler for Vulkan / OpenCL. Everything else in "pro" package is open source already. There is still legacy OpenCL implementation, but I guess ROCm will be used for everything soon.
They are also entirely useless without the userland software that is doing all the actual work. The kernel drivers are just glorified task and memory managers.
I thought that the Lima and Panfrost projects included an open-source userland component too.
And of course just generally vendor kernel code tends to have superfluous middle layers or abuse kernel interfaces in unintended ways.
Given that the most frequently cited reason that these drivers should be open source is improved user experience (less breakage when the kernel changes, easier install), what would be the advantage of an out of tree open source driver?
Ditto for the HDMI PHY, you can spin up Xorg with a fully libre stack on nearly any of the Allwinner boards from OrangePi, FriendlyARM, etc. The Mali GPU is really only useful for OpenGL ES (aka video games).
The "fun" part with these drivers is FDT attachment, but work is ongoing in FreeBSD on this.
https://www.raspberrypi.org/trademark-rules/
And competition is good.
Trademarks are complicated things mostly created by lawyers who have spent centuries building through loopholes and attempting to fix them. I'd say they serve a real useful purpose and are relatively well balanced against the interests of the populous (once you stop using one, you usually lose it). But they're by no means simple.
And desktop use is not the only thing you can do with these boards, and pretty much any of them is better than Rpi on connectivity, which is what matters for other use cases.
Let's just start out by saying that the GPU designer, ARM, does not support the Open Source driver. Most likely due to their IP-licensing scheme relying on charging customers for the hardware IP and then again charging them for the drivers that they are going to need. Previously the rumors went that they charged customers a 3rd time if they wanted OpenCL support. This is part of the reason why OpenCL on mobile is dead.
As for actual OpenCL support for Mali GPUs using the Open Source stack, work is progressing, but we (the Mesa & Clover) project aren't there yet.
Regarding the RPi, I don't think it has ever had OpenCL support. Proprietary or otherwise. About the RPi, Broadcom (the SOC designer) recently lost their very talented GPU driver engineer, due to not being serious enough about pushing the Open Source driver forward.
To answer your question about OpenCL on the RPi in practical terms, it's not possible to use the GPU. But you can use POCL for CPU-backed OpenCL support.
I'm very surprised that ARM, the company that should provide proper software references for its ecosystem, is not open source friendly.
ARM chips are just System-on-Chips with random pins soldered to random shit and broken, non-upstreamable kernels that are only released after a phone has been out for like 6 months.
It's a shit system for any type of truly open development:
This driver offers full OpenGL acceleration and does not depend on the ARM's propriety blobs. They re-created all the, as you call it, "interesting stuff" from the user space library.
Edit: I take back what I said, I misunderstood the comment. Indeed, the interesting stuff is in the userspace counter part of this kernel code.
I'm also curious, how does performance compare to the binary blob?
The same problem is with drivers. Maybe there is a way to allow drivers with closed source code and get better hardware support? For example, what about copying or supporting Android's driver model?
Proprietary drivers are shipped with many distributions. For example nvidia drivers are shipped with Ubuntu. If the repo drivers don't suit you, you can (just like on all other platforms) download drivers from the vendors website.
Proprietary drivers are allowed and are shipped in many distros (just like in Android), but they cannot be included in the kernel upstream (then they wouldn't be proprietary).
Every vendor is welcome and encouraged to submit their driver to the upstream linux kernel project. Some vendors do however chose not to do so, for a variety of terrible-to-mediocre reasons.
You can't just throw a pile of code over the fence and assume it will be accepted.
When adding support for your device keep in mind that this is something everyone wants, maintainers/users/vendors alike.
This is simply false, because AppDirs and AppImage existed long before those. And of course static binaries existed since the beginning. Sadly, Linux user space is such a horrific mess that none of those much simpler and saner solutions took off, so now we have to put up with non-portable garbage like Snap and Flatpak that are still tied to a repo model.
And main reason for this is because package managers were not designed for third-party software. They were designed only to install software from a distribution and maybe from your private repositories.
That makes proprietary software "not welcome" in Linux distributions.
Good. That means it won't break because someone arbitrarily changed an ABI.
> That makes proprietary software "not welcome" in Linux distributions.
No disagreement there.
You shouldn't be telling the developers what they should or shouldn't be doing either.
How is this unexpected?
So you either give them root access or install and update software manually. Because package managers like apt do not have a sane method to install third-party proprietary software.
And even with open source software, it is a bad method. For example, a developer that provides a Debian repository with different versions of PHP, has overwriten openssl library for users of his repository despite it can break something else.
So there should be a safer way to install third-party software.