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

AMD Releases Open-Source R600/700 3D Code

Michael Larabel

Published on 29 December 2008
Written by Michael Larabel
Page 1 of 3 - 198 Comments

Since earlier this year we have been waiting for AMD to release documentation and/or code on the ATI R600 series concerning 3D acceleration so that the open-source Linux drivers can begin to support the newer ATI graphics processors. It has taken longer than expected for AMD to complete and release this information, but it's now available. AMD has released the fundamental Linux code needed to begin fostering the development of an open-source R600 3D driver. Furthermore, this code also concerns the latest R700 series of graphics processors! The microcode for the newest GPUs has also been released.

Just hours before the start of FOSDEM 2008 in late February, AMD had released their R500 3D programming documentation. This documentation paved the way for open-source developers to begin working on a Mesa driver that would extend the earlier R300/400 series support to enable OpenGL acceleration on the Radeon X1000 series. This was also the first public documentation drop concerning 3D support since AMD's open-source strategy announcement last September. Following the 3D documentation release, two revisions were made to add in more technical details. The first revision added in just four pages while the second had detailed their command processor.

Up to that point all of the work was going into enabling mode-setting support and other basic functionality across the R500 and R600 series in the xf86-video-radeonhd driver (and then xf86-video-ati through AtomBIOS). Right after they announced their open-source initiative they had released 900 pages of specifications and then in the months that followed they released a lot more documentation.

Two weeks after the initial R500 3D documentation release, AMD had released an R300 3D register guide. This programming guide concerning their older graphics hardware was previously only available through Non-Disclosure Agreements to select developers. AMD had also released microcode for all their GPUs from their proprietary Catalyst driver.

Less than a month after the R500 3D documentation drop, the first milestone was reached: hardware-accelerated R500 glxgears. This was quite a milestone and signaled that OpenGL acceleration for the R500 series in Mesa would soon be coming. In late May there was then open-source R500 3D success with Compiz beginning to work on this relatively modern hardware along with some other OpenGL programs. As we shared in an article a day later, it was possible to game with the open-source driver using some select titles that don't stress Mesa too much. Since the point of reaching parity in the open-source support to that of earlier ATI generations, the rest of the year has not been too exciting.

Novell, AMD, and Red Hat developers have been doing a majority of the work taking advantage of the documentation, while internally at AMD they have been working to prepare the R600 documentation for release. John Bridgman and Alex Deucher have been working on deciding what code or documentation is needed for programming, sanitize it of any information not relevant to bringing up the 3D engine, remove any details concerning future ATI hardware, and then getting all of this work cleared by AMD's lead software and hardware architects so that it can be publicly released without any NDAs or other string attached. To say the least, this has taken longer than anticipated. There were a few times when it looked like the documentation and code would be coming soon, only to then be pushed back by additional hurdles, but this time around they got code to deliver too. Part of the good news out of this though is that they are continuing to refine their documentation writing process so that with future generations there may be a quicker turn-around time.

The other good news is that with the R600 series they made sure there was sufficient documentation coverage by first writing the software support to find out what was needed, instead of finding out later they hadn't released enough documentation to enable the 3D engine or they ended up releasing too much documentation than what most open-source developers would actually use. The code they are releasing is in a working state, but is currently meant for developer usage.

<< Previous Page
1
Latest Linux Hardware Reviews
  1. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  2. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  3. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
  4. AMD Radeon R9 285 Tonga Performance On Linux
Latest Linux Articles
  1. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  2. Ubuntu 14.10 XMir System Compositor Benchmarks
  3. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
  4. Ubuntu 14.10 Linux 32-bit vs. 64-bit Performance
Latest Linux News
  1. Coreboot Now Has Support For Intel Broadwell Hardware
  2. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  3. GTK+ Lands Experimental Backend For Mir Display Server
  4. Ubuntu 14.10 Officially Released
  5. Mesa 10.4 Might Re-Enable HyperZ For R600g/RadeonSI
  6. Intel GVT-g GPU Virtualization Moves Closer
  7. GTK+ 3.16 To Bring Several New Features
  8. Debian 8.0 Jessie Has Many Multimedia Improvements
  9. What Linux Benchmarks Would You Like To See Next?
  10. Open-Source, Linux Support For Corsair Link Devices Slowly Materializing
Latest Forum Discussions
  1. Linux hacker compares Solaris kernel code:
  2. Advertisements On Phoronix
  3. HOPE: The Ease Of Python With The Speed Of C++
  4. Updated and Optimized Ubuntu Free Graphics Drivers
  5. Users/Developers Threatening Fork Of Debian GNU/Linux
  6. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed