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. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  2. Intel 120GB 530 Series SSD Linux Performance
  3. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
  4. AMD's Windows Catalyst Driver Remains Largely Faster Than Linux Drivers
Latest Linux Articles
  1. Mesa Git Yields Performance Improvements For Newer AMD GPUs
  2. Apple OS X 10.10 vs. Ubuntu 14.10 Performance
  3. Mesa 10.5-devel Brings Some Intel Haswell HD Graphics Changes Over Mesa 10.3
  4. NVIDIA vs. Nouveau Drivers With Linux 3.18 + Mesa 10.4-devel
Latest Linux News
  1. GNOME 3.15.2 Released
  2. Quantum OS Aims For A Linux Desktop With QML, Wayland & Material Design
  3. New Open-Source, Linux Benchmarks To Feast On
  4. FreeBSD Plans For The Next Ten Years
  5. Qt 5.4 Planned For Release On 9 December
  6. Meizu's Ubuntu Phone Not Expected Until Early Next Year
  7. DragonFlyBSD 4.0 Drops i386 Support, Improves Graphics
  8. Expensive "Free/Libre Software Laptop" Uses A NVIDIA GPU
  9. QEMU 2.2-rc3 Released, Final Release Pushed Back By Couple Days
  10. 64-bit ARM FreeBSD Support Is Taking Shape
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. Hurrican SDL Port
  3. Roadmap to Catalyst 14.10 ?
  4. how to configure module phoromatic ?
  5. PulseAudio 6.0 Is Coming & Other Linux Audio Plans For The Future
  6. Debian Developer Resigns From The Systemd Maintainership Team
  7. Cant get working Kaveri APU - A10-7850k
  8. Script for Fan Speed Control