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. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
  2. Sumo's Omni Gets Reloaded
  3. AMD A10-7800 & A6-7400K APUs Run Great On Linux
  4. Radeon Gallium3D Is Running Increasingly Well Against AMD's Catalyst Driver
Latest Linux Articles
  1. AMD's RadeonSI Driver Sped Up A Lot This Summer
  2. Intel's Latest Linux Graphics Code Competes Against OS X 10.9
  3. Intel Sandy Bridge Gets A Surprise Boost From Linux 3.17
  4. Open-Source Radeon Graphics Have Some Improvements On Linux 3.17
Latest Linux News
  1. Intel Bay Trail Performance With Linux 3.16/3.17 & Mesa 10.3
  2. EFL Sees A Ton Of Work Following Recent v1.11 Release
  3. ARM Talks Up Wayland For Mali
  4. GNOME/GTK+ Human Interface Guidelines Updated
  5. Robocraft Is Rolling Over To Linux
  6. The Widely-Criticized New Commercial Linux Distro Is Now On Kickstarter
  7. Wayland & Weston 1.6 Alpha Released
  8. A New First-Person Mystery Game Might Be Coming To Linux
  9. Patch By Patch, LLVM Clang Gets Better At Building The Linux Kernel
  10. VC4 Gallium3D Driver Now Handles X With GLAMOR
Latest Forum Discussions
  1. OSS radeon driver for A10-7850K (Kaveri)
  2. Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs
  3. Systemd 216 Piles On More Features, Aims For New User-Space VT
  4. American Citizens running AMOK for food stamps
  5. What Linux Distribution Should Be Benchmarked The Most?
  6. Company I work for is looking to contribute to Open Source projects... but wrongly?
  7. Microsoft vs. Campaign
  8. Updated and Optimized Ubuntu Free Graphics Drivers