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. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  2. Intel 120GB 530 Series SSD Linux Performance
  3. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
  4. AMD's Windows Catalyst Driver Remains Largely Faster Than Linux Drivers
Latest Linux Articles
  1. Mesa Git Yields Performance Improvements For Newer AMD GPUs
  2. Apple OS X 10.10 vs. Ubuntu 14.10 Performance
  3. Mesa 10.5-devel Brings Some Intel Haswell HD Graphics Changes Over Mesa 10.3
  4. NVIDIA vs. Nouveau Drivers With Linux 3.18 + Mesa 10.4-devel
Latest Linux News
  1. New Open-Source, Linux Benchmarks To Feast On
  2. FreeBSD Plans For The Next Ten Years
  3. Qt 5.4 Planned For Release On 9 December
  4. Meizu's Ubuntu Phone Not Expected Until Early Next Year
  5. DragonFlyBSD 4.0 Drops i386 Support, Improves Graphics
  6. Expensive "Free/Libre Software Laptop" Uses A NVIDIA GPU
  7. QEMU 2.2-rc3 Released, Final Release Pushed Back By Couple Days
  8. 64-bit ARM FreeBSD Support Is Taking Shape
  9. GCW Zero Starts Seeing New Game Releases
  10. Intel's Cherry Trail Delayed To Next Year
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. Hurrican SDL Port
  3. Roadmap to Catalyst 14.10 ?
  4. how to configure module phoromatic ?
  5. PulseAudio 6.0 Is Coming & Other Linux Audio Plans For The Future
  6. Debian Developer Resigns From The Systemd Maintainership Team
  7. Cant get working Kaveri APU - A10-7850k
  8. Script for Fan Speed Control