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

Running The NVIDIA GeForce GTX 680 On An Open-Source Driver

Michael Larabel

Published on 26 April 2012
Written by Michael Larabel
Page 1 of 4 - 13 Comments

Thanks to clean-room reverse-engineering, it is already possible to run the NVIDIA GeForce GTX 680 "Kepler" graphics card on a fully open-source graphics driver complete with OpenGL acceleration. Here are the first benchmarks of this work-in-progress, community-created open-source GeForce 600 series graphics driver.

As mentioned on the NVIDIA GeForce GTX 680 launch-day back in March, the Nouveau project that seeks to clean-room reverse-engineer the closed-source NVIDIA driver in order to write an open-source alternative, had a huge set of surprises. Two of the Nouveau developers managed to get their hands on two GeForce GTX 680 graphics cards before launch. As a result, and since the NVIDIA driver changes from the GeForce 400/500 "Fermi" to GeForce 600 "Kepler" series were not too invasive, they managed same-day open-source driver support.

The Nouveau developers already merged their Kepler driver changes into the Linux kernel and then once the Nouveau libdrm re-write landed in mid-April, they merged their Nouveau Kepler Gallium3D code. This published code already allows for OpenGL 2.1 acceleration on Kepler graphics processors with this fully open-source driver, but there is still a lot of work left.

Like the other GeForce hardware on the Nouveau driver, the developers still working out proper re-clocking support, proper power/fan management, OpenGL 3.0+ support, merging OpenCL, etc. Additionally, the open-source Kepler support currently requires closed-source firmware for operation. In order to obtain this Kepler firmware/microcode, the official NVIDIA Linux driver must first be loaded on the hardware while running MMIOtrace within the Linux kernel to trace register writes, following by dumping the traces back into certain files in order to come up with this "FUC" microcode. This is a temporary issue and in a future Linux kernel release there should be a better solution, similar to the initial Nouveau Fermi FUC microcode situation.

<< Previous Page
1
Latest Linux Hardware Reviews
  1. AMD Launches New FX CPUs, Cuts Prices On Existing Processors
  2. Preview: AMD's FX-9590 Eight-Core At Up To 5.0GHz On Linux
  3. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  4. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
Latest Linux Articles
  1. LLVM Clang 3.5 Brings Some Compiler Performance Improvements
  2. Ondemand vs. Performance CPU Governing For AMD FX CPUs On Linux 3.17
  3. How Intel Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers
  4. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
Latest Linux News
  1. POCL Is Maturing Well For Running OpenCL On The CPU
  2. New Group Calls For Boycotting Systemd
  3. The Features To Find With The Imminent Release Of LLVM/Clang 3.5
  4. Borderlands 2 Is Coming To Linux
  5. The Witcher 2 Ups The Performance More & Works Around Catalyst Bug
  6. Running Gallium3D's LLVMpipe On The Eight-Core 5GHz CPU
  7. Trying Intel OpenCL On Linux For Video Encoding
  8. GSoC 2014 Yielded Some Improvements For Mesa/X.Org This Year
  9. webOS Lives On As LuneOS With New Release
  10. Marek Lands Radeon Gallium3D HyperZ Improvements
Latest Forum Discussions
  1. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  2. nv and xorg.conf under Debian PPC
  3. AMD graphics doesn't work with AMD Catalyst drivers
  4. Best Radeon for a Power Mac G5?
  5. The dangers of Linux kernel development
  6. Updated and Optimized Ubuntu Free Graphics Drivers
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. SSD seems slow