NVIDIA Releases 295.33; Kepler Gallium3D Soon

On the same-day as releasing the NVIDIA GeForce GTX 680 as the first GeForce graphics card based upon the new Kepler architecture, there's a binary driver update from NVIDIA that ushers in the official Kepler Linux support. There's also more surprising news out of the reverse-engineering Nouveau camp, on top of their surprises earlier today.

The NVIDIA 295.33 driver for x86/x86_64 Linux introduces official support (earlier 295.xx releases should already have pre-released support) for the GeForce GTX 680, GeForce GT 630M, and GeForce GT 620. Besides the new hardware enablement, there's a VDPAU bug-fix for H.264 streams on lower-end GPUs causing poor performance and corruption, a DisplayPort audio fix, improved compatibility with recent kernels (proper Linux 3.3 kernel support), fixed DisplayPort connector behavior, GVO NV-CONTROL attribute changes, a DisplayPort reporting fix for the X log, support for 3D Visions on displays with a built-in NVIDIA 3D Vision infrared emitter, and a few other bug-fixes.

So even if you didn't run out to the store today to buy a GeForce GTX 680 "Kepler", this driver is worth upgrading to if you're a user of NVIDIA's binary driver since there's bug-fixes and more out of the 295.33 release.

The latest NVIDIA Linux drivers can be obtained from NVIDIA.com. NVIDIA has also passed along word that with their next release series after 295.xx (likely to be 298.xx or 300.xx series), their Linux driver will now be enabling OpenGL sync-to-vblank by default. Enabling sync-to-vblank can reduce any tearing issues, but makes for a restricted benchmarking experience. (To the Phoronix Test Suite soon I'll add in support that similar to enforcing vblank_mode=0 for the open-source drivers that for the NVIDIA binary driver it will enforce SyncToBlank=0 with NVIDIA's respective protocol.)

Since the Phoronix article earlier talking about the GeForce GTX 680 Linux support, I've since confirmed with NVIDIA Corp that -- like Fermi -- there is no Kepler overclocking support under Linux at this time. There's no word on any other missing features from the Linux blob.

In other Nouveau news, besides the surprise this morning that Ben Skeggs of Red Hat had an early GeForce GTX 680 for which he was able to bring up mode-setting support already in time for the Linux 3.4 kernel (Kepler mode-setting is similar to the Fermi-based NVD9, etc), there's more related -- and exciting -- news. It turns out at least one other Nouveau developer also ended up with an early Kepler graphics card.

I'm told by Nouveau's Martin Peres that the Nouveau Gallium3D maintainer also has had his hands on a card. Best of all, "it seems 3D is mostly the same", "Kepler isn't disruptive", and "once the new libdrm is merged and the context-switching microcodes are done, we'll be to enjoy 3d accel :)" So we're not actually too far out from seeing Nouveau Gallium3D working for the GeForce 600 Kepler series!

If the community-based Nouveau developers can manage OpenGL acceleration on the GeForce 600 series for the Linux 3.5 kernel and Mesa 8.1 this summer that will certainly be welcome and a huge surprise. It's actually somewhat of an embarrassment for AMD since they only began releasing Radeon HD 7000 series code this week when the hardware has been shipping for months. With AMD's open-source approach, while they have an official open-source strategy, they have a restrictive legal and review process internally that generally holds up new hardware enablement until well after new product launches, etc. (Intel meanwhile has no problems pushing out new hardware support easily a year in advance.)

As far as how Nouveau developers managed to get early access to Kepler to begin their reverse-engineering work, that isn't too clear at the moment. David Airlie of Red Hat mentioned in our forums that the cards weren't sent by NVIDIA itself, so it may have been a NVIDIA AIB partner another source. More information when available.