NVIDIA Talks Of Optimus Possibilities For Linux

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.