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 Radeon R9 290: Gallium3D vs. Catalyst Drivers
  2. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  3. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
  4. Sumo's Omni Gets Reloaded
Latest Linux Articles
  1. 20-Way Radeon Comparison With Open-Source Graphics For Steam On Linux Gaming
  2. Preview: OS X 10.10 Yosemite vs. Ubuntu Linux GPU Performance
  3. Radeon Graphics Yield Mixed Results With Linux 3.17 Kernel
  4. AMD's RadeonSI Driver Sped Up A Lot This Summer
Latest Linux News
  1. Nouveau On Oibaf PPA Is Back To Running Well
  2. Metro 2033 Redux Will Hopefully Hit Linux Real Soon
  3. New Virtual Monitor Software Might End Up On Linux
  4. Company of Heroes 2 Might Be Coming Out For Linux
  5. NIR Still Being Discussed For Mesa, LLVM Gets Brought Up Again
  6. Plasma Active Is Mostly Ported To KDE Frameworks 5
  7. Google Chrome 37 Brings Many Security Fixes
  8. MenuetOS Updated With SMP Threads & Onscreen Keyboard
  9. Mesa Has A New Release Manager
  10. Enlightenment E19 Lands Its New Wayland Compositor Code
Latest Forum Discussions
  1. AMD Releases UVD Video Decode Support For R600 GPUs
  2. Announcing radeontop, a tool for viewing the GPU usage
  3. Updated and Optimized Ubuntu Free Graphics Drivers
  4. [DB] BIOS - ACPI - data collecting
  5. It's Now Possible To Play Netflix Natively On Linux Without Wine Plug-Ins
  6. Users defect to Linux as OpenBSD removes Lynx from base system
  7. Chinese People Try To Patent Wine On ARM
  8. American Citizens running AMOK for food stamps