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

NVIDIA Talks Of Optimus Possibilities For Linux

NVIDIA

Published on 25 January 2012 10:07 AM EST
Written by Michael Larabel in NVIDIA
124 Comments

A NVIDIA Linux engineer is trying to work on code that could lead to official Optimus support under Linux, but there's a catch... And it falls outside of NVIDIA Corp as the fate of this multi-GPU notebook feature could now fall with the Linux kernel developers.

While there's been some rudimentary Optimus hacks for Linux to use notebooks that offer an integrated graphics processor and a discrete GPU (to offer maximum performance when needed but to fall-back to only powering the IGP when in a low-power mode), NVIDIA Corp hasn't provided any official Optimus support under Linux. Now there's talk of possible support, but it's potentially to be blocked by Linux kernel developers.

Robert Morell, a long-time NVIDIA Linux engineer who's worked on the Tegra support and other areas of NVIDIA graphics, requested a kernel change (and provided a patch). He's requested that the DMA-BUF symbols be exported without the GPL license attached. This would allow DMA-BUF to be used within the binary NVIDIA Linux graphics driver, the AMD Catalyst driver, and other binary graphics drivers (i.e. many ARM SoCs), etc. This was done to the mailing list last week.

DMA-BUF is a big underlying feature of the Linux 3.3 kernel that's been worked on for months by Linaro and various Linux kernel developers. DMA-BUF is a buffer sharing mechanism so that buffers can be easily and cleanly shared between various Linux kernel drivers. Simply put, this code makes it easier to share data in a standard way between different drivers.

DMA-BUF functionality has been primarily sought after by ARM SoC vendors so that they can easily share buffers between the various SoC drivers, but there's also very real uses within the desktop graphics world as well. DMA-BUF could be used for sharing buffers between multiple graphics cards (e.g. NVIDIA SLI or CrossFire) or for sharing buffers between OpenCL devices or in cases like Optimus for sharing buffers between discrete and integrated GPUs.

DMA-BUF can be easily used by the open-source graphics drivers, and NVIDIA actually wants to use this buffer sharing mechanism by their binary drivers. The change requested by Robert Morell to export the infrastructure symbols without needing to comply with the GPL would allow this support.

David Airlie is in support of this change and acknowledges its possible use by the binary blobs for the good of the Linux desktop. "The problem is the x86 nvidia binary driver does sit outside of subsystems, and I forsee wanting to share buffers with it from the Intel driver in light of the optimus hardware. Although nouveau exists and I'd much rather nvidia get behind that wrt the kernel stuff, I don't forsee that happening."

When kernel developers began raising issues about non-GPL symbols, the NVIDIA Linux engineer chimed in with a longer response:
Yes, this is one potential use case that I have in mind.

This is digressing a bit, but the binary nvidia driver is the best way that I see that we can support our users with a feature set compatible to that available to other operating systems. For technical reasons, we've chosen to leverage a lot of common code written internally, which allows us to release support for new hardware and software features much more quickly than if those of us working on the Linux/FreeBSD/Solaris drivers wrote it all from scratch. This means that we share a lot with other NVIDIA drivers, but we for better or worse can't share much infrastructure like DRI.

I only see such hardware becoming more common. For example, in the future, if we can't agree on using EXPORT_SYMBOL, then if somebody were to introduce a laptop that had a Tegra GPU (which uses GPL-compatible open-source Linux drivers) and a GeForce GPU (which is, as described above, supported by our existing binary driver) then I imagine we'd have no choice but to re-implement a different open-source buffer allocation mechanism for Tegra that could be used between the two, or just continue using our existing nvhost code. This, along with every other SoC's version, is exactly what the dma-buf project was intended to replace.

So NVIDIA is actually talking about NVIDIA Optimus support under Linux! Robert also mentions an interesting -- possible -- Optimus configuration we haven't yet seen where a laptop would have a Tegra GPU as the low-power solution and then a higher-end GeForce GPU as the discrete solution. (This would also mean an ARM version of the mainline GeForce Linux driver.) It looks like NVIDIA clearly wants to enable such Optimus support under Linux based upon the patch so their binary driver can use DMA-BUF for its buffer sharing. But not all kernel developers support out-of-tree drivers, especially those that are not compliant with the GNU GPL.

At large, kernel developers are largely objecting to this patch on moral/legal beliefs. Robert has persisted to find out how this change can possibly move forward. Simply having an open-source (GPL) shim sitting between DMA-BUF and the blob doesn't look like it would bypass the legal restrictions. "It really seems to me that this change on a technical level won't have any adverse effect on the scenarios where it can be used today, but it will allow it to be used more widely, which will prevent duplication and fragmentation in the future and be greatly appreciated by users of hardware such as Optimus."

Alan Cox is one of the developers objecting to the change. As usual, some just call for NVIDIA to open up their driver.

If the kernel developers won't allow this symbol exporting change, NVIDIA will just need to forget about the new features under Linux or instead develop their own in-house buffer sharing system for the kernel. Developing another mechanism would -- as said by Morell -- defeat the purpose of DMA-BUF as this infrastructure was developed after there was already enough fragmentation in the Linux world by ARM driver developers. The open-source graphics drivers (Intel, Radeon, Nouveau) would additionally then need to comply with that buffer sharing mechanism too. This is sad seeing as there are many Linux desktop end-users that could benefit from the support.

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. Even With Re-Clocking, Nouveau Remains Behind NVIDIA's Proprietary Linux Driver
  2. The Power Consumption & Efficiency Of Open-Source GPU Drivers
  3. AMD R600g/RadeonSI Performance On Linux 3.16 With Mesa 10.3-devel
  4. Intel Pentium G3258 On Linux
Latest Linux Articles
  1. AMD Catalyst 14.6 Does Slightly Better With APITest OpenGL Tests
  2. Updated Source Engine Benchmarks On The Latest AMD/NVIDIA Linux Drivers
  3. Nouveau vs. Radeon vs. Intel Tests On Linux 3.16, Mesa 10.3-devel
  4. KVM Benchmarks On Ubuntu 14.10
Latest Linux News
  1. Builder: A New Development IDE Being Built For GNOME
  2. GDB 7.8 Betters Python Scripting, Adds Guile Support
  3. GNOME's GTK+ Is Still Striving For A Scene Graph, Canvas API
  4. Unreal Tournament Looks Great For Team Deathmatch
  5. LibreOffice 4.3 Released With Many Exciting Changes
  6. GNOME/GTK On Wayland Gains Focus At GUADEC
  7. GNOME Stakeholders Take Issue With Groupon Over their Gnome
  8. GStreamer VA-API Plug-In Update Adds New Features
  9. Qt 5.4 Going Into Feature Freeze Next Week With Exciting Changes
  10. OpenSUSE Factory Turns Into Rolling Release Distribution
Latest Forum Discussions
  1. Open-source drivers on ATI R7 260X
  2. Grand Theft Auto Running On Direct3D Natively On Linux Shows Gallium3D Potential
  3. AMD Athlon 5350 APU On Linux
  4. Debian + radeonsi
  5. Linus Torvalds On GCC 4.9: Pure & Utter Crap
  6. Updated and Optimized Ubuntu Free Graphics Drivers
  7. List of Linux friendly Kickstarter projects
  8. Porting Mesa to the Playstation 2