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's Working On A New Driver Architecture?

NVIDIA

Published on 05 December 2010 04:58 PM EST
Written by Michael Larabel in NVIDIA
22 Comments

When going over the mailing list messages from the past few days regarding concerns over NVIDIA's fence sync patches for X.Org Server 1.10, one of the statements by NVIDIA's James Jones indicates that they are working on a new driver architecture. What though could this new driver architecture hold in store?

In response to Keith Packard's proposed compromise for how to handle the fence synchronization patches, James Jones was rightfully a bit annoyed that this technical feedback had not come until months after NVIDIA put out the original patches and just days before the xorg-server 1.10 merge window is about to close. This is when James came to say that NVIDIA's synchronization rendering problem has been around for years and he would really like to get these patches into xorg-server 1.10 and then with a 1.10 point release or in the 1.11 release to properly clear up the documentation and give the approval (or disapproval) to compositing window manager maintainers and others whether using the DamageSubtractAndTrigger functionality is safe to rely upon.

James' second paragraph of this message though went on to say NVIDIA's driver regardless would be non-compliant with implicit synchronization for the "foreseeable future" as it would simply be too much work to implement it with reasonable performance on their current architecture. However, that's when James goes on to say they are working on a new architecture whereby it would be easier to implement the implicitly synchronized behaviour of the said extension.
- Our drivers are going to be non-compliant in regard to the implicitly synchronized behavior for the foreseeable future. It is truly a mountain of work to implement it with reasonable performance in our current architecture. We're slowly adapting to an architecture where it'd be easier, and we could fix it at that time, but I doubt I'll get time to before then. I can live with being no compliant. Apps have grudgingly accepted the quasi-defined behavior of texture-from-pixmap "loose binding" mode for years to get the performance benefits it offers.

This is the first time we're hearing of a new driver architecture from NVIDIA. Though mentioning that they are "slowly adapting" to it dissolves some hope of it coming soon (the NVIDIA 300.xx driver series?) and that it may be more of an evolutionary step in their driver architecture rather than revolutionary.

We have sent over an email to NVIDIA to try to get more information on this new driver architecture. Seeing as NVIDIA's proprietary Linux driver shares a common code-base with their Windows driver and also their FreeBSD/Solaris support, it does lead us to believe that such a new architecture would continue to be shared across all platforms.

The NVIDIA Linux driver right now is at a near performance parity with the Windows build, again as the code-base is common across all supported platforms aside from the OS-specific bits, and there is a near feature parity too. Though recently the feature support on Linux has dropped behind with the GeForce GTX 400/500 "Fermi" GPUs on Linux currently lacking overclocking support as well as multi-GPU SLI support. NVIDIA's Optimus technology is also currently unsupported on Linux.

If this is a major advancement to NVIDIA's driver architecture, it would be ideal if this work does provide support for kernel mode-setting and ultimately for fostering Wayland support, although NVIDIA has no plans to support Wayland at this time. Of course, it would also be good to properly support the Resize and Rotate (RandR) extension, seeing as it should now be easier to support with RandR 1.4.

Besides that, it's becoming more difficult to think what architectural changes would be needed by their closed-source driver: it's already fast with both 2D and 3D acceleration, there's support for the latest OpenGL and OpenCL specifications, video acceleration is superb with VDPAU (though support for VP8 and other open formats would be nice), and there aren't too many driver problems. It was a year ago that we interviewed Andy Ritger and there were no major breakthroughs then, but perhaps it's time again for another Linux interview (a.k.a. post questions to our forums if there is interest)?

Before someone thinks otherwise, however, this new architecture would not be a migration to the Gallium3D architecture (it's too immature still at this point, would be a regression compared to their current driver architecture, does not support all of NVIDIA's requirements, etc) or likely not some other major open-source breakthrough.

What else would you like to see improved within NVIDIA's proprietary graphics driver? Share with us in the forums while we await any word from NVIDIA.

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. Acer B286HK: A 28-inch UHD LED 4K Monitor For As Low As $350
  2. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  3. Intel 120GB 530 Series SSD Linux Performance
  4. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
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. Devuan: Debian Without Systemd
  2. Wine 1.7.32 Updates Its Mono Engine
  3. Mesa 10.4 Release Candidate 3 Is Here For Weekend Testing
  4. GenodeOS 14.11 Now Supports Intel's Wireless Hardware
  5. Jolla Tablet Could Have Upgrades For MicroSDHC, Split Screen, 3.5G
  6. Intel Has Last Round Of DRM Changes For Linux 3.19, Starts Dropping DRI1/UMS
  7. Fedora 21 Release Candidate 1 Awaits Your Testing
  8. GCC 5 Adds Support For ARM's Cortex-A17
  9. KWayland Server Component Coming For KDE Plasma 5.2
  10. NVIDIA Posts Tegra Gallium3D Patch For K1+ Support
Latest Forum Discussions
  1. Aliens vs predator for Linux
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Hurrican SDL Port
  4. Roadmap to Catalyst 14.10 ?
  5. how to configure module phoromatic ?
  6. PulseAudio 6.0 Is Coming & Other Linux Audio Plans For The Future
  7. Debian Developer Resigns From The Systemd Maintainership Team
  8. Cant get working Kaveri APU - A10-7850k