| |||||||||||||
Free drivers for ARM graphicsFree drivers for ARM graphicsPosted Sep 26, 2013 23:01 UTC (Thu) by khim (subscriber, #9252)In reply to: Free drivers for ARM graphics by dlang Parent article: Free drivers for ARM graphics
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.
(Log in to post comments)
Free drivers for ARM graphics Posted Sep 27, 2013 1:29 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
>> 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 Posted Sep 27, 2013 7:21 UTC (Fri) by khim (subscriber, #9252) [Link] 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. 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 Posted Sep 27, 2013 14:37 UTC (Fri) by robclark (subscriber, #74945) [Link]
> 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 Posted Sep 28, 2013 4:00 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
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 Posted Sep 28, 2013 12:05 UTC (Sat) by robclark (subscriber, #74945) [Link]
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).
|
|||||||||||||