Embedded GPUs On Linux Remain A Great Big Mess

Written by Michael Larabel in Hardware on 21 December 2010 at 10:36 PM EST. 10 Comments
For anyone that happens to be on holiday this week (or just have excess time otherwise), there is another lively and polarized discussion that's been taking place for the past several days on the DRI mailing list. What does it involve if it's not about developer disagreements amongst themselves? Embedded GPU driver support on Linux, of course. This mailing list thread just reaffirms how the situation is a great big mess.

For those that haven't already been following this thread or don't have the time to catch up, it just started out as a thread within the Linaro mailing list about reviewing the Freescale Linux BSP code and how to handle it within the Linaro project, which again is the Linux project attempting to unify the ARM platform.

One of the big parts of this Freescale Linux BSP code is a kernel graphics driver. It's open-source, great. But, like the Qualcomm Snapdragon graphics driver and most other embedded GPU Linux drivers (and some of VIA's previous Chrome DRM code), the open-source kernel driver is only good if pairing it with a closed-source user-space component.

Once it was confirmed this newest code was still bound by a closed-source library, the discussion spewed onto the DRI development mailing list. Some though, such as Linaro's Jammy Zhou, proposed the kernel code be integrated into the Linaro kernel tree regardless and then adding the closed-source user-space binaries to the Linaro hardware pack. This though would go against the Linaro policy of pulling in kernel code that's not on its way to hitting the mainline tree. An alternative would be to create a separate, not-officially-maintained Git tree of the Linaro kernel but with all of the kernel graphics bits integrated that are dependent upon being banged from closed-source software.

Besides the legal and philosophical reasons for not accepting open-source Linux kernel code that's only used by closed-source clients, there are technical reasons too. Like not being able to easily audit the code for security holes, being bound to an API/ABI that's just designed for use by the closed-source client, etc.

With GPU drivers, one of the security holes can come from having a GPU driver that could read the system memory. That's why the Radeon DRM driver (and other open-source DRM/KMS drivers) have a command checker to provide some safeguards. Around this time in the thread, Matt Sealey began commenting. Matt Sealey is a Product Development Analyst for Genesi. Genesi is a vendor of ARM-based devices.

Genesi's Sealey began by commenting that worrying about host memory access by the GPU driver is an unneeded worry and then to express his views on kernel driver licensing. "Ownership of the code is dependent on who licensed it. I do not think Linaro need be so concerned over opensourcing or reimplementing drivers. The fact that the kernel driver is open source as it is, and this is by far the most important part. The userspace library is closed because it is proprietary; and I think it is well outside Linaro's remit to lobby for opensourcing of proprietary code simply to meet an esoteric and needless demand for source code access (as it stands, you can get source code access by signing the usual plethora of NDAs with the appropriate vendor, as Genesi has done)."

After Jerome Glisse responded asking whether Matt was indeed saying that all open-source code should be accepted into the Linux kernel simply because the code is open-source, this Genesi employee had another entertaining message. Here was his next message.
The code may need improvement but that's no reason to run around saying everything needs to be open sourced, and that the solution is in fact to reverse engineer the thing rather than accept it as the current solution. Given how long nouveau and later Radeon card support has taken in real life, even with full documentation from AMD, I seriously doubt Linaro are going to be the ones to somehow make the world change for OpenSource embedded GPU graphics. Linaro doesn't exist just to spend all their time undermining the status quo for the sake of it.

I also do not think that it is at all kernel policy to disallow kernel drivers which do not have opensource userspace components. In fact, Linus Torvalds begs to differ on this matter. The fact of the matter is that the driver lives now, Qualcomm have it in their upstream, Freescale have it in their upstream, Linaro are going to fetch from that. It doesn't need to go all the way to stable, because people can compile their own kernels if they want (and Linaro is there provide the source to do that with the best interoperability with the silicon vendors' chips as possible).

Well, good luck reverse engineering the GPU in the next 5 years, because I suspect that is how long it is going to take.

I would love to see someone actually, physically prove that using the libraries provided by vendors (Freescale's BSP, or from Genesi or so) and the kernel driver committed, that you CAN actually cause rampant, unsecured graphical corruption, before a discussion goes around to those vendors about spending the next 6 months mired in legal work trying to find all the potential IP sources and seek approval to publish that code as opensource or perform rewrites. So far I don't see that, just a "I'm fairly sure" from a trusted person. This is not peer review, it's pure opinion. Go see how well you can break it, submit a bug report, the vendors might fix it in the closed source libraries or publish a kernel driver update to suit your needs.

Matt had also ended his earlier message with, "Can't we all just be happy that we actually have 3D drivers?" David Airlie then jumped into the thread.
Can't you just use Windows? why bother with open source at all if you are willing to give up.

My point which people keep missing is that graphics stacks are a single entity, that span kernel and userspace, one cannot exist without the other, and there are interfaces that join them.

I will accept kernel code to initialise chips, set modes, do all that, I won't accept new ioctl interfaces to userspace that cannot be validated and have no use other than to serve the closed user blob. The reason for this is the burden of maintaining the code/interfaces falls onto the kernel community when we accept code. Now if we can no longer validate that the interfaces work without running a binary blob or we cannot change the interfaces without having to lobby some other entity to change their blob then maintaining that code in the upstream kernel is pointless.

I have no problem with closed 3D drivers I just want the manufacturers to understand that if you want to go down that path you get to keep both halves.

After messages from Alan Cox and others, the Genesi Product Development Analyst got back on the list providing his views on code legal advice and more insightful views from a hardware vendor that doesn't seem to understand Linux.
There is no legal issue here. It is not going into mainline, fair enough. What I am curious about is why did Linaro push it to dri-devel in the first place? I think the concept of taking a driver from a BSP and then just FLINGING it at mainline is not responsible in the first place. Isn't it enough to go into the Linaro tree, discretely and quietly? Then we can have a discussion about what to do about it within Linaro.

It looks like the embedded GPU Linux driver situation will continue to be a mess going into 2011, though there have been some hints otherwise. But at least this messy situation provides for some entertainment on the DRI mailing list.
Related News
About The Author
Author picture

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week