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. Scythe Mugen MAX
  2. Intel Core i7 5960X Haswell-E On Linux
  3. Intel 80GB 530 Series M.2 SSD On Linux
  4. With A New Motherboard, The Core i7 5960X Haswell-E Lights Up
Latest Linux Articles
  1. A Tour Of The New Phoronix Office
  2. 7-Way Linux Desktop Gaming Comparison On Ubuntu 14.10
  3. Intel P-State vs. CPUFreq Benchmarks On The i7-5960X
  4. RadeonSI GLAMOR Benchmarks With X.Org Server 1.16
Latest Linux News
  1. Linux 3.17-rc6 Released; Linux 3.17 Final Might Come In One Week
  2. X.Org Server 1.16.1 Released
  3. Mesa Gets Closer To Having OpenGL 4.0 Tessellation Support
  4. Uselessd: A Stripped Down Version Of Systemd
  5. F2FS Tools Gain FSCK Support
  6. FreeBSD 10.1 Has The New VT Driver, Hardware Improvements
  7. AntiMicro 2.6 Yields Greater Compatibility For Gamepads On Linux
  8. OpenGL 3.3 / GLSL 3.30 Lands For Intel Sandy Bridge On Mesa
  9. AMD's RadeonSI Gallium3D Driver Sees Some Improvements
  10. Mesa 10.3 Released With The Latest Open-Source GPU Driver Improvements
Latest Forum Discussions
  1. X.Org Women Outreach Program Only Turns Up Two Applicants So Far
  2. Uselessd: A Stripped Down Version Of Systemd
  3. Wasteland 2 Officially Launched Today, Including For Linux Gamers
  4. NVIDIA GTX 770/780 -works ?
  5. Trolling on the Phoronix forums
  6. New stress testing utility for GPU's
  7. ASRock AM1H-ITX: One Of The Best AM1 Mini-ITX Motherboards
  8. Can Linux kill a motherboard?