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 Benchmarking Platform
Phoromatic Test Orchestration

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 Linux News
  1. Mesa Git OpenGL Tests With Intel Ivy Bridge Graphics
  2. Blender 2.75 Allows For AMD OpenCL Support
  3. GNOME's Mutter 3.17.2 Adds X11/Wayland Clipboard Interoperation
  4. Wayland 1.8 RC2 Arrives Along With New Weston Compositor Release
  5. LLVM 3.7 Is Planned For A Late August Release
  6. The OpenGL ES 3.1 Foundation Is Being Laid In Mesa
  7. There Are 140k Benchmark Results So Far On LinuxBenchmarking.com
  8. LLVM 3.6.1 Brings R600 & MIPS Fixes
  9. Friction Building Around An Ubuntu Community Council Decision
  10. Bye Bye Mandriva, She's Being Liquidated
Latest Articles & Reviews
  1. Opening The Gates To Our Daily Open-Source Linux Benchmark Results
  2. The Latest Features For Linux Performance Management + Benchmark Monitoring
  3. Noctua NH-U12DX i4 + NF-F12
  4. Btrfs RAID 0/1 Benchmarks On The Linux 4.1 Kernel
Most Viewed News This Week
  1. The Linux 4.0 EXT4 RAID Corruption Bug Has Been Uncovered
  2. NVIDIA's Proprietary Driver Is Moving Closer With Kernel Mode-Setting
  3. Systemd 220 Has Finally Been Released
  4. Microsoft Open-Sources The Windows Communication Foundation
  5. Zapcc Claims To Be A "Much Faster C++ Compiler"
  6. LibreOffice 5.0 Beta 1 Released
  7. Another HTTPS Vulnerability Rattles The Internet
  8. LibreOffice 5.0 Open-Source Office Suite Has Been Branched