LWN: Comments on "Free drivers for ARM graphics"

Free drivers for ARM graphics

glaesera — 2013-10-01T06:25:45+00:00

GPUs seem to be the main obstacle these days, that prevent people from using their cutting-edge hardware with free software exclusively.
See there:
https://www.fsf.org/resources/hw/single-board-computers
I can still live without any ARM-machines, because I have similar problems with PC-hardware already, RADEON-GPUs for example just will not deliver any 3D-accelleration without the non-free firmware. One can not afford to be too fundamentalistic there.

OpenGL drivers review

meuh — 2013-09-30T14:41:28+00:00

Just found an article on how good/bad are OpenGL drivers from the dolphin-emu developers point of view (dolphin-emu is a GPLv2 Nintendo GameCube/Wii emulator):

https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-...

This article acknowledge the good work made on open source/free software reverse engineered drivers.

Free drivers for ARM graphics

robclark — 2013-09-28T12:13:47+00:00

> Renesas and Mediatek are two SoC vendors that ship large volumes of SGX GPUs, although they are mainly in China and less present in Europe and North America. The Allwinner A31 (unlike A10, A13 and A20) uses SGX as well, but that might turn out a one-time mistake like the previous Exynos5 (5410) that gets rectified in the next version. Still, I don't think there is much hope that the products just go away.

I wouldn't be surprised if some (esp. samsung) keep making a few devices w/ sgx in the near future as a hedge and/or bargaining chip when it comes to discussing cost/schedule with ARM. I suspect sgx 5xx does still have a slight power advantage against mali (would explain why you see it in the exynos5 targeted at phones), although in the area where sgx once was king, they are fading fast.

> On the plus side, the company is actually opening up slightly now, as they are getting their feet wet with contributing upstream Linux architecture support for their Meta CPUs as well as by getting involved in MIPS Linux (ImgTec recently bought MIPS Technologies). I hope they eventually follow the lead of Nvidia, who are also (slowly) getting more open about their GPUs after becoming involved in the community with their Tegra SoCs. Realistically I think it won't happen before we have upstream support on all other major GPUs and they start seeing pressure from the market.

it really would be nice to see IMGtech open up. And ironically (considering how hostile they have been to open src in the past) they are the ones with the most to gain and the least to lose by opening up. Closed source and buggy are really not a great combination.

Free drivers for ARM graphics

robclark — 2013-09-28T12:05:01+00:00

To me, a graphics driver is something that drives the hardware, lets me implement new extensions and compiler features, fix bugs that effect me, etc.

opengl is too high level, especially when you take glsl into account.

The closest equivalent in a more traditional gpu architecture to what is open in rp-i would be an open EGL layer (which would let you implement support for wayland or some new window system). The r-pi does have some advantage that libc version isn't a problem, but even that isn't too big of an issue w/ something like libhybris (which would be a considerably more simple thing if it didn't have to emulate one EGL on top of another).

Free drivers for ARM graphics

dlang — 2013-09-28T04:00:28+00:00

Thanks for the clarification.

What is it that defines a "graphics driver" as far as you are concerned?

my view has been that whatever code the OS needs to run to get the pixels on the screen would be the graphics driver and it doesn't matter if the mechanism to control the bits is bit manipulation in video memory (i.e. framebuffer), passing openGL commands directly to the GPU, or even selecting which characters to put where to implement 'graphics' on a vt100 screen.

Free drivers for ARM graphics

arnd — 2013-09-27T19:02:31+00:00

There are also technical issues with SGX, to the point that people are being discouraged of even looking at it.

There are other GPUs that have an even smaller market share and nobody working on them:

* Creative Labs / Ziilabs (formerly 3D Labs) ZMS: almost nonexisting in the market, so nobody bothered reverse engineering so far, but interesting technoloy. Part of Ziilabs was apparently sold to Intel last year.

* Samsung "fimg": this was the first reverse-engineering project for an ARM GPU, now at https://github.com/tom3q/openfimg/wiki, but unfortunately Samsung abandoned their own GPU design before it had a chance to get anywhere. The s3c64xx/s5p64xx SoCs were once popular but this was in the ARM11/ARMv6 age.

* Broadcom VideoCore IV. The Raspberry Pi was already mentioned, which uses VideoCore IV as the "main" CPU and an ARM11 to run Linux. There are actually phone SoCs based on modern ARM cores with VideoCore IV used exclusively as the GPU. I don't think there is any work on free GPU drivers for those chips, although reverse-engineering the instruction set (as someone mentioned in another post here) is certainly going to help.

* HTC bought the "S3" GPU division from VIA some time ago. Chances are that they are planning to come out with a new SoC for HTC phones with their own GPU at some point. At the moment those are just rumors at best,
so no software (neither proprietary nor free).

* IIRC WonderMedia had their own GPU at some point but moved to Mali now. I don't know any details, but I assume this was a fixed-function GPU, no programmable shaders.

* Digital Media Professionals Inc. has an OpenGL ES3.0 GPU called SMAPH that is used in some Renesas SoCs, and an earlier GPU that was used in the Nintendo 3DS. That's all I know about them.

* Takumi has an OpenGL ES2.0 GPU called gs3000. No word about their customers.

Free drivers for ARM graphics

arnd — 2013-09-27T18:22:27+00:00

Renesas and Mediatek are two SoC vendors that ship large volumes of SGX GPUs, although they are mainly in China and less present in Europe and North America. The Allwinner A31 (unlike A10, A13 and A20) uses SGX as well, but that might turn out a one-time mistake like the previous Exynos5 (5410) that gets rectified in the next version. Still, I don't think there is much hope that the products just go away.

On the plus side, the company is actually opening up slightly now, as they are getting their feet wet with contributing upstream Linux architecture support for their Meta CPUs as well as by getting involved in MIPS Linux (ImgTec recently bought MIPS Technologies). I hope they eventually follow the lead of Nvidia, who are also (slowly) getting more open about their GPUs after becoming involved in the community with their Tegra SoCs. Realistically I think it won't happen before we have upstream support on all other major GPUs and they start seeing pressure from the market.

Free drivers for ARM graphics

robclark — 2013-09-27T14:37:26+00:00

> complaining that they aren't 'real' drivers because they don't give you low enough access to the device is like complaining that your disk controller no longer gives you the ability to manually step the heads and you are limited to asking it to just give you a block.

Let me clarify here. I'm certainly not complaining about what bcom has released for r-pi. It is better than what is available from the other SoC GPU vendors. (Well, ironically, the EGL plugin API (wsegl) is available for some older powervr drivers, which is something roughly equivalent, although only slightly worse because you have to still care about libc version, hardfloat/softfloat, etc)

The only thing I complain about is people who call it a graphics driver, when it very clearly is not.

Free drivers for ARM graphics

khim — 2013-09-27T07:21:40+00:00

no, the binary blobs that run in the kernel address space interact with kernel locking.

There are no blobs in kernel space if you run Linux using VMWare. It's all “on the outside”.

the R-pi drivers don't suffer any of these problems.

VMWare does not suffer from these problems either. It uses different techniques from r-pi (virtualization vs separate silicone) but the end result is the same.

complaining that they aren't 'real' drivers because they don't give you low enough access to the device is like complaining that your disk controller no longer gives you the ability to manually step the heads and you are limited to asking it to just give you a block.

Well, sure, I often use this example myself to show that gNewSense is somewhat hypocritical (it removes “unfree fimrware” from it's repository but can not really be used on a free systems without one: old 386/486 systems which had no binary blobs are not really powerful enough and all contemporary systems rely on non-free BIOS and non-free firmware in HDD, etc).

But there are big practical difference: HDD API changes are very slow and bugs are quite rare. With GPU it's direct opposite: bugs are frequent, and progress is rapid. That's why we really need GPU drivers and that's why we don't care all that much about HDD firmware.

or complaining that a modem only accepts AT commands, you can't use it as a sound card the way you can use a winmodem

Sure. I don't even remember when I've last used modem for the landline, but of course the fact that radiomodules are completely closed affairs on contemporary smartphones is a problem (and people tackle this problem, too).

no, most have blobs in kernelspace and/or userspace as well as in firmware, the r-pi eliminates the userspace/kernelspace binary blobs.

Which mobile chipsets are using kernel-level blobs? I think only nVidia does that and it's not all that popular. The rest are using userspace blobs and completely free shims in kernel - exactly like r-pi is doing except their blobs can be constrained (like any binary userspace program) while r-pi blob basically drives the whole circus.

The r-pi drivers could be used not only for X, but can be modified to work for Wayland, Mir, *BSD, or any other OS that wants to run on that hardware.

Binary drivers don't allow that.

Really? Have you heard about hybris project? It's can be used today to run Wayland, Mir, *BSD, or any other OS that wants to run on that hardware. Well, it can run Wayland and Mir at least, but I don't see what will prevent anyone from using it on *BSD.

It's not like they re-wrote everything to do this either, this is the architecture they created from the beginning, and why they warned people that getting the source for the kernel drivers wouldn't be very interesting.

Well, sure. They designed their chip to make sure they can separate it in two parts. Not uncommon design - only usually it's done to separate radiopart from main CPU, here it's done to separate GPU from CPU. It does mean we suddenly got open-source GSM drivers (in the form of list of AT commands) and it does not mean we suddenly got open-source GPU drivers for r-pi. Both are useful, both are closed source.

Free drivers for ARM graphics

dlang — 2013-09-27T01:29:13+00:00

>> if you want to modify the firmware you are correct, but if you just want to work with the linux kernel, the ABI/API into the firmware is defined and the drivers to access it are fully open source.

>Well, by this logic ALL AMD/nVidia cards have fully-opensourced drivers. You only need to load few binary blobs (namely Windows, video card driver for Windows and VMWare) and you are golden: ABI/API into the “firmware” is defined and defined and the drivers to access it are fully open source.

no, the binary blobs that run in the kernel address space interact with kernel locking. The binary blob drivers have to be changed from one kernel release to the next (remember when a major distro, I think Fedora, delayed an update because the proprietary drivers were not ready yet?)

the R-pi drivers don't suffer any of these problems.

complaining that they aren't 'real' drivers because they don't give you low enough access to the device is like complaining that your disk controller no longer gives you the ability to manually step the heads and you are limited to asking it to just give you a block.

or complaining that a modem only accepts AT commands, you can't use it as a sound card the way you can use a winmodem

> Only most have their blobs in userspace, r-pi have it in firmware.

no, most have blobs in kernelspace and/or userspace as well as in firmware, the r-pi eliminates the userspace/kernelspace binary blobs.

It's not like they re-wrote everything to do this either, this is the architecture they created from the beginning, and why they warned people that getting the source for the kernel drivers wouldn't be very interesting.

The r-pi drivers could be used not only for X, but can be modified to work for Wayland, Mir, *BSD, or any other OS that wants to run on that hardware.

Binary drivers don't allow that.

Free drivers for ARM graphics

khim — 2013-09-26T23:01:37+00:00

if you want to modify the firmware you are correct, but if you just want to work with the linux kernel, the ABI/API into the firmware is defined and the drivers to access it are fully open source.

Well, by this logic ALL AMD/nVidia cards have fully-opensourced drivers. You only need to load few binary blobs (namely Windows, video card driver for Windows and VMWare) and you are golden: ABI/API into the “firmware” is defined and defined and the drivers to access it are fully open source.

Now, I'm not RMS and I would not refuse to r-pi for that reason: it's still an interesting piece of hardware, there are no doubt about it. But it's drivers are most definitely not open-sourced.

The problem is that some people refuse to accept this, and say that since someone can compile new firmware for the GPU, they won't accept 'merely' having everything that's compiled into the kernel be open source, they want the GPU firmware as well.

Well, sure. They have the exact same status most other mobile drivers have. Only most have their blobs in userspace, r-pi have it in firmware. Practically speaking there are no difference. Well, binary blob in userspace is easier to confine thus I will name r-pi situation slightly worse then others, but not by much.

Free drivers for ARM graphics

robclark — 2013-09-26T22:16:36+00:00

> if you want to modify the firmware you are correct, but if you just want to work with the linux kernel, the ABI/API into the firmware is defined and the drivers to access it are fully open source.

Well, I don't know any actual graphics driver developer who will call what is available for r-pi kernel and userspace a "graphics driver"

> The problem is that some people refuse to accept this, and say that since someone can compile new firmware for the GPU, they won't accept 'merely' having everything that's compiled into the kernel be open source, they want the GPU firmware as well.

The only way r-pi stuff qualifies as an open/free "graphics driver" is in PR wordsmithing. Yes they have managed to game the system nicely. No it is not an open source graphics driver.

Yes, it's nice for the community, and much better than nothing. But it is off topic, wrt. my talk.

> never mind that no GPU gives you the ability to modify the firmware.

nouveau does develop it's own open src firmware.

I do hope to see more open firmware on other drives, although since on all other GPUs the firmware is considerably lower level (in most cases, basically a fancy register-writer), dealing with the firmware problem has been much lower on the priority list.

> as a side note, I'll bet that you could buy a developer kit for that chip and it would give you a (probably closed source) compiler that you could use to compile your own code for it. That is after all how they deal with anyone else who wants to use that chip in a device.

Sure. And plenty of people/companies have access to (for example) powervr or mali src code (under NDA, of course). Doesn't really help much.

Free drivers for ARM graphics

dlang — 2013-09-26T21:46:36+00:00

if you want to modify the firmware you are correct, but if you just want to work with the linux kernel, the ABI/API into the firmware is defined and the drivers to access it are fully open source.

The problem is that some people refuse to accept this, and say that since someone can compile new firmware for the GPU, they won't accept 'merely' having everything that's compiled into the kernel be open source, they want the GPU firmware as well.

never mind that no GPU gives you the ability to modify the firmware.

as a side note, I'll bet that you could buy a developer kit for that chip and it would give you a (probably closed source) compiler that you could use to compile your own code for it. That is after all how they deal with anyone else who wants to use that chip in a device.

Free drivers for ARM graphics

ncm — 2013-09-26T20:37:54+00:00

If there were any project that I had some glimmer of hope of persuading Matthew Garrett to jump into, this would be it.

Selfishly, I would hope he chose the Etnaviv effort.

Free drivers for ARM graphics

robclark — 2013-09-26T15:10:37+00:00

you are thinking of SGX (or the new generation, RGX).. I suppose most people just sort of hope that IMGtech will wither up and go away, which seems like it is well on the way to happening.. ie. OMAP and related TI parts aren't much volume anymore, intel has switched to their own GPU, and apple is rumored to be working on their own GPU.

Free drivers for ARM graphics

robclark — 2013-09-26T15:05:51+00:00

as far as I know, there isn't too much to report yet on r-pi. Because of the architecture with the entire gpu on the co-processor, there is a lot more basic groundwork (like writing a compiler for the co-processor, which does seem to be making some progress, fwiw) before you can really even start playing with the GPU.

Free drivers for ARM graphics

pabs — 2013-09-26T13:04:28+00:00

i.MX6 has Vivante GPUs. For PowerVR based SoCs there is a reverse-engineering project started but there are not many people working on it unfortunately:

http://powervr.gnu.org.ve/

Free drivers for ARM graphics

rvfh — 2013-09-26T09:45:41+00:00

The big one missing is IMX, AKA Imagination (OMAP, IPad, latest Exynos...)

AIUI, Rob worked on Adreno because he could not work on Imagination as he was employed by TI at the time, and had potentially access to the source code. He did manage to use GPL'd header files to pull some 2D out though.

Free drivers for ARM graphics

pabs — 2013-09-26T05:53:32+00:00

Some references to work on that:

https://github.com/hermanhermitage/videocoreiv
http://blog.emmanueldeloget.com/index.php?post/2013/03/08...

Free drivers for ARM graphics

dlang — 2013-09-26T02:36:44+00:00

many people don't consider those drivers free enough, because the code in the kernel isn't complicated enough (the firmware in the GPU implements calls so that the kernel driver is not much more than
foo()
return GPU_foo()
}

Free drivers for ARM graphics

allesfresser — 2013-09-26T02:30:09+00:00

It's a pity the GPU in the RaspberryPi isn't on the list. (Unless I missed something...)