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

There's Hope For DMA-BUF With Non-GPL Drivers

NVIDIA

Published on 20 February 2012 07:16 AM EST
Written by Michael Larabel in NVIDIA
43 Comments

There's some resurrected hope for the kernel symbols of the DMA-BUF buffer sharing mechanism to be not restricted to only GPL drivers, which started off as a request by NVIDIA. This could lead to better NVIDIA Optimus support under Linux, among other benefits.

DMA-BUF is the buffer sharing mechanism for the Linux kernel that was introduced in the 3.3 cycle for zero-copy sharing of buffers between kernel drivers. This work originally came out of the Linaro project since there's a need for such a mechanism by various ARM SoC driver developers. However, there's also benefits to this work when it comes to GPU hot-plugging, OpenCL / GPGPU computing, and multi-GPU configurations like NVIDIA Optimus.

To learn more about DMA-BUF for Linux, watch this DMA-BUF video from FOSDEM 2012 when Daniel Vetter of Intel was speaking about this infrastructure.

Back in January there was a request by NVIDIA that the DMA-BUF kernel symbols be not exported GPL-only, which would prevent them from taking advantage of this buffer sharing mechanism in their proprietary driver. This would inhibit them from being able to easily/cleanly share buffers between their binary driver and say the Intel open-source driver in Optimus cases where there's both Intel and NVIDIA graphics. Or for buffer-sharing between an open-source NVIDIA Tegra kernel driver and the binary driver with a GeForce GPU, a case that one of the requesting NVIDIA engineer mentioned.

The upstream open-source Linux kernel developers weren't really in favor of this change to allow non-GPL drivers access to DMA-BUF. However, one of the developers involved with DMA-BUF, Rob Clark of Texas Instruments, has more positive news to now share. Below is the message he posted to the kernel mailing list on Sunday concerning this DMA-BUF licensing.
We discussed this topic at the kernel-gfx mini-summit at ELC. Following the discussion, I agree that dma-buf infrastructure is intended as an interface between driver subsystems. And because (for now) all the other arm SoC gl(es) stacks unfortunately involve a closed src userspace, and since I consider userspace and kernel as tightly coupled in the realm of graphics stacks, I don't think we can really claim the moral high-ground here. So I can't object to use of EXPORT_SYMBOL() instead of EXPORT_SYMBOL_GPL().

That said, I expect the dma-buf infrastructure to still be evolving and it is the responsibility for out-of-tree users of the API (GPL or otherwise) to adapt as the dma-buf API changes. And there isn't much the in-tree drivers can do when it comes to debugging of buffer sharing issues with out-of-tree drivers (binary or otherwise), leaving the debugging responsibility to the owners of different out-of-tree drivers.

BR,
-R

This would be marked as a win for NVIDIA (and potentially AMD, among others) as well as Linux desktop users just looking for the best supported hardware experience, assuming this export symbol change goes through.

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. AMD Launches New FX CPUs, Cuts Prices On Existing Processors
  2. Preview: AMD's FX-9590 Eight-Core At Up To 5.0GHz On Linux
  3. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  4. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
Latest Linux Articles
  1. LLVM Clang 3.5 Brings Some Compiler Performance Improvements
  2. Ondemand vs. Performance CPU Governing For AMD FX CPUs On Linux 3.17
  3. How Intel Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers
  4. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
Latest Linux News
  1. POCL Is Maturing Well For Running OpenCL On The CPU
  2. New Group Calls For Boycotting Systemd
  3. The Features To Find With The Imminent Release Of LLVM/Clang 3.5
  4. Borderlands 2 Is Coming To Linux
  5. The Witcher 2 Ups The Performance More & Works Around Catalyst Bug
  6. Running Gallium3D's LLVMpipe On The Eight-Core 5GHz CPU
  7. Trying Intel OpenCL On Linux For Video Encoding
  8. GSoC 2014 Yielded Some Improvements For Mesa/X.Org This Year
  9. webOS Lives On As LuneOS With New Release
  10. Marek Lands Radeon Gallium3D HyperZ Improvements
Latest Forum Discussions
  1. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  2. nv and xorg.conf under Debian PPC
  3. AMD graphics doesn't work with AMD Catalyst drivers
  4. Best Radeon for a Power Mac G5?
  5. The dangers of Linux kernel development
  6. Updated and Optimized Ubuntu Free Graphics Drivers
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. SSD seems slow