Open source Mali GPU drivers merged • Hacker News Board

Re: Open source Mali GPU drivers merged

#21

Post by q3k » Tue, May 14, 2019, 1:28 PM UTC

maeln wrote: post #20

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.

It's arguable in the case of ARM/Mali but sadly, there is for NVidia. 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.

They could do the same thing AMD did, which is keep their game/application API optimizations secret within a proprietary userspace stack, but also make it work with the open source Mesa/Gallium3d stack. Leave the OpenGL/Vulkan software development part to software developers (or keep doing it yourself if you think it's that important), but at least tell us how to drive your hardware.

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.

Re: Open source Mali GPU drivers merged

#22

Post by nextos » Tue, May 14, 2019, 1:30 PM UTC

Gregordinary wrote: post #14

Jonnax wrote: post #2

What devices can be used with these drivers? 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?

There's a Chromebook, the Asus C201 that will benefit from this. I'm currently running PrawnOS (Debian-based) on it. Wrote a bit about that on reddit: https://old.reddit.com/r/linux/comments/bebm93/linux_on_asus... 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…

Indeed. This machine is truly unique in the sense that it can be run with no binary blobs. To achieve this one had to disable GPU and WiFi (and use e.g. an Atheros adapter).

Now GPU acceleration will be achievable via open source.

Re: Open source Mali GPU drivers merged

#23

Post by floatboth » Tue, May 14, 2019, 1:30 PM UTC

q3k wrote: post #19

gugagore wrote: post #18

Earlier quoted context omitted.

What is their reasoning?

I don't work for ARM Holdings, so I don't know. 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'.

Often it's a mess of third party proprietary dependencies, code owned by subcontractors, etc.

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.

Re: Open source Mali GPU drivers merged

#24

Post by floatboth » Tue, May 14, 2019, 1:33 PM UTC

Gregordinary wrote: post #14

Jonnax wrote: post #2

What devices can be used with these drivers? 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?

There's a Chromebook, the Asus C201 that will benefit from this. I'm currently running PrawnOS (Debian-based) on it. Wrote a bit about that on reddit: https://old.reddit.com/r/linux/comments/bebm93/linux_on_asus... 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…

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

Re: Open source Mali GPU drivers merged

#25

Post by Gregordinary » Tue, May 14, 2019, 1:37 PM UTC

floatboth wrote: post #24

Gregordinary wrote: post #14

Earlier quoted context omitted.

There's a Chromebook, the Asus C201 that will benefit from this. I'm currently running PrawnOS (Debian-based) on it. Wrote a bit about that on reddit: https://old.reddit.com/r/linux/comments/bebm93/linux_on_asus... 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…

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

#26

Post by floatboth » Tue, May 14, 2019, 1:37 PM UTC

messe wrote: post #17

What license? Are they, like the intel and radeon gpu drivers, importable into OpenBSD/FreeBSD?

FreeBSD does not import GPU drivers into base, they're now packaged and under the GPL (they depend on some GPL code imported from Linux).

The "fun" part with these drivers is FDT attachment, but work is ongoing in FreeBSD on this.

Re: Open source Mali GPU drivers merged

#27

Post by 0xcde4c3db » Tue, May 14, 2019, 1:38 PM UTC

neilv wrote: post #8

I'm not sure these exact GPUs are supported yet, but this sounds like good news for mainline Linux on Samsung smartphone hardware: https://wiki.postmarketos.org/index.php?search=mali&title=Sp...

Note that most flagship Samsung phones have US variants based on a Qualcomm Snapdragon SoC (Adreno GPU) instead of an Exynos. This seems to be for US-specific reasons related to a legal battle between Samsung and Qualcomm rather than being driven by technology requirements.

Re: Open source Mali GPU drivers merged

#28

Post by trasz » Tue, May 14, 2019, 1:49 PM UTC

floatboth wrote: post #26

messe wrote: post #17

What license? Are they, like the intel and radeon gpu drivers, importable into OpenBSD/FreeBSD?

FreeBSD does not import GPU drivers into base, they're now packaged and under the GPL (they depend on some GPL code imported from Linux). The "fun" part with these drivers is FDT attachment, but work is ongoing in FreeBSD on this.

That's the current situation - but the drivers themselves are mostly free of GPL; the GPL-derived parts in linuxkpi can be (and eventually will) be rewritten to make them BSD-licensed, and that would make it possible to go back to importing GPU drivers into base, if the DRM developers wish so.

Re: Open source Mali GPU drivers merged

#29

Post by grw_ » Tue, May 14, 2019, 1:54 PM UTC

gugagore wrote: post #18

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.

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, but harder.

Re: Open source Mali GPU drivers merged

#30

Post by djsumdog » Tue, May 14, 2019, 1:54 PM UTC

kbumsik wrote: post #12

I don't know much about ARM SoC ecosystems for Linux, but am I correct if I take this as a direct ARM Mali version of Nouveau, or it's slightly different? I'm very surprised that ARM, the company that should provide proper software references for its ecosystem, is not open source friendly.

There is no actual ARM platform, like in the case of a PC. (Intel x86/64 is not a platform. You can find an x86 compatible chip in a PS4, but it's missing all of the critical components that let it boot like a PC. See the Fail0ver video on PS4 kernel hacking for more info).

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:

https://penguindreams.org/blog/android-fragmentation/