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 Releases 295.33; Kepler Gallium3D Soon

NVIDIA

Published on 22 March 2012 06:36 PM EDT
Written by Michael Larabel in NVIDIA
10 Comments

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.

Latest Linux Hardware Reviews
  1. Overclocking The AMD AM1 Athlon & Sempron APUs
  2. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
  3. Upgraded Kernel & Mesa Yield A Big Boost For Athlon R3 Graphics
  4. AMD Athlon 5350 APU On Linux
Latest Linux Articles
  1. A Quick Look At GCC 4.9 vs. LLVM Clang 3.5
  2. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
  3. AMD Athlon's R3 Graphics: RadeonSI Gallium3D vs. Catalyst
  4. GCC 4.9 Compiler Optimization Benchmarks For Faster Binaries
Latest Linux News
  1. Trying Out Radeon R9 290 Graphics On Open-Source
  2. Intel Broadwell GT3 Graphics Have Dual BSD Rings
  3. Early Linux 3.15 Benchmarks Of Intel Core i7 + Radeon
  4. Red Hat Releases Its RHEL 7 Release Candidate
  5. New Features Coming To Xubuntu 14.04 LTS
  6. NVIDIA Officially Releases CUDA 6
  7. Google Releases An AutoFDO Converter For Perf In LLVM
  8. Fedora 21 To Evaluate Remote Journal Logging, 64-bit ARM Emulation
  9. Star Citizen Will Be Coming To Linux
  10. Ubuntu 14.10 Convergence To Focus On Replacing Core Apps
  11. The Results Of Optimizing Radeon's VRAM Behavior
  12. Kernel Developers Discuss Improving Kernel Configurations
Latest Forum Discussions
  1. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  2. The GNOME Foundation Is Running Short On Money
  3. Bye bye BSD, Hello Linux: A Sys Admin's Story
  4. New tool for undervolt/overclock AMD K8L and K10 processors
  5. How to enable opengl 3.3 on r9 270?
  6. R290x sound problems
  7. radeon-profile: tool for changing profiles and monitoring some GPU parameters
  8. Torvalds Is Unconvinced By LTO'ing A Linux Kernel