Open source Mali GPU drivers merged • Hacker News Board

Re: Open source Mali GPU drivers merged

#51

Post by robert_foss » Tue, May 14, 2019, 3:40 PM UTC

anonymousDan wrote: post #47

Do any of the Mali GPUs support GPGPU (e.g. OpenCL), and are those drivers being open sourced? In fact, if I wanted to do GPGPU on something like a Raspberry Pi, what are the best options currently (open source drivers or not)?

The ARM Mali T-series and G-series of GPUs do support compute (OpenCL), the drivers are a different story.

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.

Re: Open source Mali GPU drivers merged

#52

Post by robert_foss » Tue, May 14, 2019, 3:43 PM UTC

q3k wrote: post #13

The fact that ARM has not made their Mali drivers open source is a joke. There's no excuse, same for Nvidia.

This is most likely due to ARMs 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. As far as the rumors go, they used to charge customers a 3rd time if they wanted OpenCL support.

Re: Open source Mali GPU drivers merged

#53

Post by robert_foss » Tue, May 14, 2019, 3:44 PM UTC

stefan_ wrote: post #33

q3k wrote: post #13

The fact that ARM has not made their Mali drivers open source is a joke. There's no excuse, same for Nvidia.

Strictly speaking the kernel drivers for the ARM Malis are all open-source and GPL licensed (they need to be, since their customers want to ship Linux to consumers). 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.

While the kernel driver is Open Source, they have decided to implement a driver that can _never_ be submitted upstream for Kernel inclusion.

Re: Open source Mali GPU drivers merged

#54

Post by codedokode » Tue, May 14, 2019, 3:47 PM UTC

Linux still is not friendly to proprietary code. To install third-party software user often has either to run a bash script with root privileges that can potentially break the system, or add a proprietary repository (which allows its owner to replace any software on user's machine). Before flatpack and snapcraft there was no sane way to install third-party software.

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?

Re: Open source Mali GPU drivers merged

#55

Post by robert_foss » Tue, May 14, 2019, 3:55 PM UTC

codedokode wrote: post #54

Linux still is not friendly to proprietary code. To install third-party software user often has either to run a bash script with root privileges that can potentially break the system, or add a proprietary repository (which allows its owner to replace any software on user's machine). Before flatpack and snapcraft there was no sane way to install third-party software. The same problem is with drivers. Maybe there is a…

Is this trolling or are you serious?

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.

Re: Open source Mali GPU drivers merged

#56

Post by robert_foss » Tue, May 14, 2019, 3:57 PM UTC

simcop2387 wrote: post #43

ddtaylor wrote: post #6

This should help a bit with the wave of new Pi-based emulation boards that are being used.

Won't affect any raspberry pi based systems. the Broadcom chip there isn't Mali based. For that you need a VC4/V3D chip driver, but that's also being developed. https://anholt.github.io/twivc4/2018/10/30/twiv/

Well, the VC4/V3D was maintained until recently. Broadcom is no longer employing anyone to develop it.

Re: Open source Mali GPU drivers merged

#57

Post by ynnn » Tue, May 14, 2019, 4:00 PM UTC

codedokode wrote: post #54

Linux still is not friendly to proprietary code. To install third-party software user often has either to run a bash script with root privileges that can potentially break the system, or add a proprietary repository (which allows its owner to replace any software on user's machine). Before flatpack and snapcraft there was no sane way to install third-party software. The same problem is with drivers. Maybe there is a…

There are a number of things that could be done to improve the experience with proprietary drivers, but all of them undermine the Linux driver philosophy. For the kernel community, any driver that is not mainlined is doing it wrong (and there are a number of compelling arguments behind this position), so the out of tree / proprietary driver experience is intentionally not improved.

Re: Open source Mali GPU drivers merged

#58

Post by AnIdiotOnTheNet » Tue, May 14, 2019, 4:00 PM UTC

codedokode wrote: post #54

Linux still is not friendly to proprietary code. To install third-party software user often has either to run a bash script with root privileges that can potentially break the system, or add a proprietary repository (which allows its owner to replace any software on user's machine). Before flatpack and snapcraft there was no sane way to install third-party software. The same problem is with drivers. Maybe there is a…

> Before flatpack and snapcraft there was no sane way to install third-party software.

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.

Re: Open source Mali GPU drivers merged

#59

Post by ynnn » Tue, May 14, 2019, 4:04 PM UTC

robert_foss wrote: post #55

codedokode wrote: post #54

Linux still is not friendly to proprietary code. To install third-party software user often has either to run a bash script with root privileges that can potentially break the system, or add a proprietary repository (which allows its owner to replace any software on user's machine). Before flatpack and snapcraft there was no sane way to install third-party software. The same problem is with drivers. Maybe there is a…

Is this trolling or are you serious? 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 wo…

Welcomed and encouraged to submit their driver for consideration. I would guess that the vast majority of vendor-proprietary drivers would get rejected from upstream, so for most cases the viable options for vendors wishing have an driver in mainline are to improve an existing reverse-engineered driver or rewrite the driver to fit the kernel standards.

Re: Open source Mali GPU drivers merged

#60

Post by megous » Tue, May 14, 2019, 4:05 PM UTC

codedokode wrote: post #54

Linux still is not friendly to proprietary code. To install third-party software user often has either to run a bash script with root privileges that can potentially break the system, or add a proprietary repository (which allows its owner to replace any software on user's machine). Before flatpack and snapcraft there was no sane way to install third-party software. The same problem is with drivers. Maybe there is a…

Linux is much more than general distros and closed source drivers are pain in the ass for everybody. Vendors should just mainline the support for their HW, especially if they benefit from Linux overall.