Earlier quoted context omitted.
What is their reasoning?
I forget where I read this, but I recall that due to patent situation it's practically impossible to build a GPU without infringing on some patent or another. By keeping drivers closed source it's possible to maintain deniability- if ARM released open source GPU drivers it would be trivial for rights-holders to look at the implementation and see what they can sue for. It's not impossible to do this with blob drivers,…
Open source Mali GPU drivers merged
91–100 of 104 posts
Re: Open source Mali GPU drivers merged
#92Earlier quoted context omitted.
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/
There are many more '* Pi' boards than just Raspberry Pi. A lot (most) of them have ARM GPU.
Re: Open source Mali GPU drivers merged
#93Are any odroid SBCs affected?
Re: Open source Mali GPU drivers merged
#94Earlier quoted context omitted.
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.
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.
Re: Open source Mali GPU drivers merged
#95Earlier quoted context omitted.
Linux isn't supposed to be friendly to developers wanting to rob people of their rights.
But as a user, I want to be able to use proprietary applications in a safe way, so that they cannot steal my browser cookies or read my MAC address, or patch my kernel. So I would prefer that Linux distributions support proprietary apps like Android Open Source Project does, rather than tell me what I should use and what I shouldn't.
Re: Open source Mali GPU drivers merged
#96Earlier quoted context omitted.
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…
Thanks for the detailed comment! Regarding OpenCL on RPi, what about something like this: https://hackaday.com/2019/01/24/running-opencl-on-a-raspberr... Do you think it could support ML training/inference on a Pi GPU (albeit very slowly obviously), or even OpenCV?
Re: Open source Mali GPU drivers merged
#97Earlier quoted context omitted.
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/
There are many more '* Pi' boards than just Raspberry Pi. A lot (most) of them have ARM GPU.
Re: Open source Mali GPU drivers merged
#98Earlier quoted context omitted.
Does the new DRM driver currently work with Wayland compositors? I know Alyssa has demonstrated Weston on Panfrost, but that might've been with ARM's kernel driver or something
Yup, it supports Weston. Possibly more as it does say it supports some Wayland compositors, but only mentions Weston in the example: https://panfrost.freedesktop.org/building-panfrost-mesa.html
Re: Open source Mali GPU drivers merged
#99Earlier quoted context omitted.
> 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 stil…
You can compile a static binary or distribute a private copy of libraries, but it doesn't get you integrated into the system. For example, your app will not be upgraded using a package manager. 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…
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.
Re: Open source Mali GPU drivers merged
#100Earlier quoted context omitted.
Yup, it supports Weston. Possibly more as it does say it supports some Wayland compositors, but only mentions Weston in the example: https://panfrost.freedesktop.org/building-panfrost-mesa.html
It's broken at present, due to exposing BUFFER_AGE which isn't properly implemented. Should be fixed in mesa 19.2.