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. A Walkthrough Of The New 32 System Open-Source Linux Benchmarking Test Farm
  2. Habey MITX-6771: Mini-ITX Board With Quad-Core J1900 Bay Trail
  3. OCZ Vector 150 SSD On Linux
  4. Noctua i4 CPU Cooler: Great For Cooling High-End LGA-2011v3 CPUs
Latest Linux Articles
  1. AMD Kaveri: Open-Source Radeon Gallium3D vs. Catalyst 14.12 Omega Driver
  2. 12-Way AMD Catalyst 14.12 vs. NVIDIA 346 Series Linux GPU Comparison
  3. AMD Catalyst 14.12 Omega Driver Brings Mixed Results For Linux Users
  4. 6-Way Winter 2014 Linux Distribution Comparison
Latest Linux News
  1. MIPS R6 Architecture Now Supported By GCC
  2. LowRISC To Feature Tagged Memory & Minion Cores
  3. Intel Skylake Audio Support For Linux 3.19
  4. After 10+ Years, NetworkManager Reaches v1.0
  5. VDPAU Updated To v0.9
  6. An Open Hardware Random Number Generator Proposed
  7. LLVM 3.6 Will Be Branched Next Month
  8. Opera Browser Puts Out Linux Updates For The Holidays
  9. GNOME Shell 3.15.3 Adds Support For High-Contrast Themes
  10. Linux 3.19: ThinkPad Muting Redone, New Dell Backlight Support, Acer Is Banging
Latest Forum Discussions
  1. XLennart: A Game For Systemd Haters With Nothing Better To Do
  2. Need some hand holding with upgrading xserver
  3. Updated and Optimized Ubuntu Free Graphics Drivers
  4. Debian init discussion in Phoenix Wright format
  5. The New SuperTuxKart Looks Better, But Can Cause GPU/Driver Problems
  6. FPS capped on Linux (AMD fglrx drivers)
  7. Are there an app using HSA ?
  8. Bench specific mount point