Linux Developers Still Reject NVIDIA Using DMA-BUF

Written by Michael Larabel in NVIDIA on 11 October 2012 at 06:52 AM EDT. 258 Comments
NVIDIA
Going back to the beginning of this year there's been talk of NVIDIA looking at Optimus support for Linux and in August they confirmed they were working on NVIDIA Optimus Linux support. As part of their Optimus Linux implementation they want to use DMA-BUF for the multi-GPU interactions just like the open-source drivers, so that they can all work together. However, kernel developers continue to reject this notion.

Back in January was when a request was made by NVIDIA to change the DMA-BUF symbols for dealing with the shared buffers to be exported under EXPORT_SYMBOL rather than EXPORT_SYMBOL_GPL. At the moment with the EXPORT_SYMBOL_GPL usage, DMA-BUF can't be used by non-GPL kernel drivers, i.e. ruling out the possibility of the proprietary NVIDIA or AMD Catalyst drivers sharing buffers with the open-source DRM drivers so that Optimus support and other similar technologies could work out on the Linux desktop. This also rules out any non-GPL ARM SoC drivers from sharing buffers with open-source drivers because of GPL purists at the cost of better Linux driver interoperability.

In February it looked like DMA-BUF would be changed to allow for non-GPL driver support, but now it seems that the DMA-BUF symbols will remain GPL-only.

NVIDIA's Robert Morell sent out a patch on Wednesday to the mailing lists that changed the DMA-BUF symbols for buffer importing and exporting to be EXPORT_SYMBOL rather than the GPL version. However, this patch was quickly dismissed by some Linux kernel developers.

Red Hat's Mauro Carvalho Chehab sent over his negative-acknowledgement as did Alan Cox. "NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view as a (and the view of many other) rights holder to the kernel likely to be in breach of the GPL requirements for a derivative work. You may consider that formal notification of my viewpoint. Your corporate legal team can explain to you why the fact you are now aware of my view is important to them."

Rob Clark of Texas Instruments is the only open-source Linux developer on the thread so far not objecting to making DMA-BUF work with non-GPL drivers. "Well, for my contributions to dmabuf, I don't object.. and I think because we are planning to use dma-buf in userspace for dri3 / dri-next, I think that basically makes it a userspace facing kernel infrastructure which would be required for open and proprietary drivers alike. So I don't see much alternative to making this EXPORT_SYMBOL(). Of course, IANAL."

Rob also raises a valid point about how DMA-BUF is also becoming critical to DRI3 (DRI-Next).

So while many Linux desktop users are quick to bash NVIDIA over their lack of proper Optimus support, right now they are also being forced down by the Linux kernel developers not wanting to allow non-GPL drivers to use this unified buffer sharing infrastructure and reducing driver interoperability.
Related News
About The Author
Michael Larabel

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