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

Why The Radeon Gallium3D Performance Is Down

Michael Larabel

Published on 23 December 2011
Written by Michael Larabel
Page 2 of 4 - 16 Comments

Combine the Phoronix Test Suite with a fast Intel CPU and most any change in performance can be quickly located. With the OpenArena Mesa 7.12-devel drop in frame-rate this was no different. The Radeon X1950PRO graphics card was again used from the Core i7 870 desktop, all the details are hosted on this OpenBenchmarking.org page.

So what did the Phoronix Test Suite find? The performance drop in OpenArena for the current Mesa 7.12-devel Git head is caused by ef64da8f013691c66744064769db379e57ef95de -- a.k.a. winsys/radeon: don't use the new GEM_WAIT ioctl for now -- was the biggest offender that's currently impairing the OpenArena performance for the RV570 graphics card. This change by Marek Olšák to the Radeon winsys for Gallium3D simply disables using the GEM_WAIT ioctl code-path, even when a Linux kernel is in use that supports this particular ioctl.

This commit is not too terribly surprising, since the GEM_WAIT ioctl is known to increase performance (particularly for CPU-bottlenecked graphics workloads) and is talked about in this Phoronix article. The DRM_RADEON_GEM_WAIT ioctl was only introduced a few months back, so unless using a very new Linux kernel snapshot chances are you would not have noticed the boost in performance in the first place. Here is a partial explanation of this work from when Marek was originally pushing the kernel changes:

Sometimes we want to know whether a buffer is busy and wait for it (bo_wait). However, sometimes it would be more useful to be able to query whether a buffer is busy and being either read or written, and wait until it's stopped being either read or written. The point of this is to be able to avoid unnecessary waiting, e.g. if a GPU has written something to a buffer and is now reading that buffer, and a CPU wants to map that buffer for read, it needs to only wait for the last write. If there were no write, there wouldn't be any waiting needed.

This, or course, requires user space drivers to send read/write flags with each relocation (like we have read/write domains in radeon, so we can actually use those for something useful now).

However, the DRM_RADEON_GEM_WAIT ioctl work was introduced to Mesa in August past the 7.11 release. There is another problem at hand.

Latest Articles & Reviews
  1. Intel Broadwell: GCC 4.9 vs. LLVM Clang 3.5 Compiler Benchmarks
  2. Ubuntu vs. Fedora Linux On Lenovo's X1 Carbon With Core i7 Broadwell
  3. Ubuntu 15.04 Is The Easy Path To Better Performance On Intel Broadwell
  4. NVIDIA's Latest Maxwell Line-Up Against AMD With Catalyst On Linux
  5. Preliminary Tests Of Intel Sandy Bridge & Ivy Bridge vs. Broadwell
  6. AMD FX-8320E Performance On Linux
Latest Linux News
  1. Does VirtualBox VM Have Much A Future Left?
  2. HAMMER2 File-System Is Still Slowly Coming Together
  3. The Better Looking Window Decorations For GNOME 3.16
  4. Libinput 0.9 Adds Support For Hovering Fingers On Touchpads
  5. Free Software Foundation Endorses Another (Outdated) Laptop
  6. DNF Plugins Extend The Functionality Of Fedora's Yum Successor
  7. LibreOffice 4.4 Released With Better OOXML Support, UI Improvements
  8. Inkscape 0.91 Goes Through C++ Code Conversion, New Cairo Rendering, OpenMP Filters
  9. New Mesa Patch To Improve CPU-Bound Applications
  10. LLVM Adds Options To Do Fuzz Testing
Most Viewed News This Week
  1. PlayStation 4 System Compiler Support Landing In LLVM
  2. LibreOffice 4.4 Is Coming Soon With New Features
  3. Linux "GHOST" Vulnerability Hits Glibc Systems
  4. My Initial Intel Broadwell Linux Experience With The ThinkPad X1 Carbon
  5. Broadwell Linux Ultrabook Running MUCH Cooler Than Haswell
  6. LZHAM 1.0 Lossless Data Compression Codec Released
  7. Linux Users Upset By Chromium's Busted HiDPI Support
  8. Vivaldi: A New Chromium-Powered, Multi-Platform Browser