1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Linux Developers Still Reject NVIDIA Using DMA-BUF

NVIDIA

Published on 11 October 2012 06:52 AM EDT
Written by Michael Larabel in NVIDIA
258 Comments

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.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. MSI X99S SLI PLUS On Linux
  2. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  3. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  4. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
Latest Linux Articles
  1. Open-Source Radeon 2D Performance Is Better With Ubuntu 14.10
  2. RunAbove: A POWER8 Compute Cloud With Offerings Up To 176 Threads
  3. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  4. Ubuntu 14.10 XMir System Compositor Benchmarks
Latest Linux News
  1. Dead Island GOTY Now Available On Linux/SteamOS
  2. Ubuntu 14.04 In The Power8 Cloud From RunAbove
  3. KDE With Theoretical Client-Side Decorations, Windows 10 Influence
  4. Sandusky Lee: Great Cabinets For Storing All Your Computer Gear
  5. Fedora 21 Beta & Final Release Slip Further
  6. Mesa 10.3.2 Has A Couple Bug-Fixes
  7. RadeonSI/R600g HyperZ Support Gets Turned Back On
  8. openSUSE Factory & Tumbleweed Are Merging
  9. More Fedora Delays: Fedora 21 Beta Slips
  10. Mono Brings C# To The Unreal Engine 4
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. HOPE: The Ease Of Python With The Speed Of C++
  3. Use Ubuntu MATE 14.10 Make it an official distro.
  4. Users/Developers Threatening Fork Of Debian GNU/Linux
  5. Debian Is Back To Discussing Init Systems, Freedom of Choice
  6. AMD Radeon VDPAU Video Performance With Gallium3D
  7. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  8. Linux hacker compares Solaris kernel code: