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 Benchmarking Platform
Phoromatic Test Orchestration

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 Articles & Reviews
  1. Sub-$20 802.11n USB WiFi Adapter That's Linux Friendly
  2. The Lenovo T450s Is Working Beautifully With Linux
  3. Linux 4.0 SSD EXT4 / Btrfs / XFS / F2FS Benchmarks
  4. Linux 4.0 Hard Drive Comparison With Six File-Systems
  5. Lenovo ThinkPad T450s Broadwell Preview
  6. How Open-Source Allowed Valve To Implement VULKAN Much Faster On The Source 2 Engine
Latest Linux News
  1. GCC 5.1 RC2 Arrives, GCC 5.1 Planned For Next Week
  2. F2FS For Linux 4.1 Has New Features & Fixes
  3. Phoronix Server Upgrade This Weekend: Dual Haswell Xeons, 96GB DDR4
  4. Google's Experimental QUIC Transport Protocol Is Showing Promise
  5. Red Hat Joins Khronos, The Group Behind OpenGL & Vulkan
  6. NetworkManager Drops WiMAX Support
  7. Wine 1.7.41 Works More On Kernel Job Objects, MSI Patches
  8. Linux 4.1 Has Improvements For The Multi-Queue Block Layer
  9. X.Org Looks To Have Six Summer Projects
  10. DragonFlyBSD Pulls In GCC 5 Compiler
Most Viewed News This Week
  1. Nouveau: NVIDIA's New Hardware Is "VERY Open-Source Unfriendly"
  2. Linux 4.0 Kernel Released
  3. Microsoft Announces An LLVM-Based Compiler For .NET
  4. Linux 4.1 Brings Many Potentially Risky x86/ASM Changes
  5. Encryption Support For EXT4
  6. VirtualBox 5.0 Beta 2 Released
  7. Mozilla Start Drafting Plans To Deprecate Insecure HTTP
  8. Elementary OS 0.3 "Freya" Now Available