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. Samsung 850 EVO SSD Linux Benchmarks
  2. Kubuntu 15.04 Is Turning Out Quite Nice, Good Way To Try Out The Latest KDE
  3. 5-Way Linux Distribution Comparison On The Core i3 NUC
  4. OCZ ARC 100 Linux SSD Benchmarks
  5. Lenovo ThinkPad X1 Carbon Works Great As A Linux Ultrabook
  6. Transcend SSD370 256GB
Latest Linux News
  1. OpenBSD Sponsors Work For Better Browser Security
  2. Improved ODF Reading Support Comes To KDE's Calligra
  3. Another Step Closer On The New Linux Benchmarking Test Farm
  4. Confirmed: Vulkan Is The Next-Gen Graphics API
  5. Kdenlive Ported To Qt5/KF5, Coming To KDE Applications 15.04
  6. HTC & Valve Partnered Up For The Steam VR Headset
  7. 8cc: A Small C11 Compiler
  8. Not Everyone Likes The Possible "VULKAN" Name For Next-Gen OpenGL
  9. The Binary Blobs Making Up Coreboot
  10. Linux 4.0 & LLVM vs. GCC Yielded Much Interest This Month
Most Viewed News This Week
  1. Screenshots Of The GNOME 3.16 Changes
  2. More Proof That Allwinner Is Violating The GPL
  3. The Tremendous Features Of Fedora 22
  4. Krita 2.9 Released, Their Biggest Release Ever
  5. A Single UEFI Executable With The Linux Kernel, Initrd & Command Line
  6. Linux 4.0 Doesn't Have The Weirdest Codename
  7. Canonical Comes Up With Its Own FUSE Filesystem For Linux Containers
  8. Firefox 36 Brings Full HTTP/2 Support
%%CLICK_URL_UNESC%%