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

HyperZ: Errata & The Catalyst Command Stream

AMD

Published on 14 July 2012 03:05 PM EDT
Written by Michael Larabel in AMD
52 Comments

Following yesterday's article about Radeon Gallium3D HyperZ support defeating open-source developers, Jerome Glisse has clarified the situation after trying to make this code work properly for more than a half-year.

Jerome Glisse's blog post from this morning is entitled Hyperz, it was a long time ago. To condense several paragraphs into something more elegant: the open-source HyperZ problems are likely due to a R600+ GPU hardware bug. However, there's nothing cited as an errata within the public documentation and its unlikely any internal AMD Catalyst driver engineers would remember the details around the issue since the hardware in question is about five years old.

Due to hardware errata, the only sure way to tell how to control the hardware is by looking at the closed-source driver's command stream to see how the binary blob is programming the hardware. However, for the open-source Gallium3D driver to mirror the Catalyst driver's command stream as it pertains to HyperZ would mean re-writing much of the Gallium3D driver.
But no matter how much i followed the AMD documentation advice, i still run into issue. I went back to look at what fglrx was doing and of course i found several things that i believe was no were documented, such as never reset htile preloading if resetting same surface, or first depth clear can't be a fast clear because you need to initialize the htile surface. Maybe i just missread or missunderstand documentation i was provided and i apologize if so.

In the end, from a register value point of view in each use case my patch now pretty much exactly match the register value fglrx uses. Yet on some specific use case i am still hitting lockup. So i am left with little option here, either i am missing a single bit somewhere (despite my automatic command stream comparison i might still miss thing). Or the order in which you do thing matter much more that what we believe ie you need to program some register in some specific order to avoid issues. I believe this is the issue i am left with, but trying to match fglrx order means huge overhaul of how r600g build its command stream.

So the fact is, in the end the closed source driver is the reference implementation that got all the informations in it. So looking at closed source driver command stream is always the saffest way to be sure to have all the informations. That's at least my opinion.
Simply put, end-users and open-source Radeon driver developers are screwed right now if hoping to reliably use the performance-boosting HyperZ feature on modern Radeon graphics card. Though if you haven't upgraded from an old ATI Radeon graphics card, at least HyperZ works on the old GPUs.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Articles & Reviews
  1. Sub-$20 802.11n USB WiFi Adapter That's Linux Friendly
  2. The Lenovo T450s Is Working Beautifully With Linux
  3. Linux 4.0 SSD EXT4 / Btrfs / XFS / F2FS Benchmarks
  4. Linux 4.0 Hard Drive Comparison With Six File-Systems
  5. Lenovo ThinkPad T450s Broadwell Preview
  6. How Open-Source Allowed Valve To Implement VULKAN Much Faster On The Source 2 Engine
Latest Linux News
  1. AMD Open-Sources "Addrlib" From Catalyst
  2. AMD Releases New "AMDGPU" Linux Kernel Driver & Mesa Support
  3. A Gigabyte Sandy/Ivy Bridge Motherboard Now Handled By Coreboot
  4. Linux 3.16 Through Linux 4.0 Performance Benchmarks
  5. Intel's Windows Driver Now Supports OpenGL 4.4, Linux Driver Still With OpenGL 3.3
  6. DRM Graphics Updates Sent In For The Linux 4.1 Kernel
  7. More eBPF Improvements Heading To Linux 4.1
  8. LLDB Is Getting Into Shape For Linux 64-bit Debugging
  9. Wine-Staging 1.7.41 Works On Improved Debugging Support
  10. GNOME 3.18 Release Schedule: 23 September Release
Most Viewed News This Week
  1. Nouveau: NVIDIA's New Hardware Is "VERY Open-Source Unfriendly"
  2. LibreOffice 4.5 Bumped To Become LibreOffice 5.0
  3. Linux Audio Is Being Further Modernized With The 4.1 Kernel
  4. KDBUS Is Taking A Lot Of Heat, Might Be Delayed From Mainline Linux Kernel
  5. VirtualBox 5.0 Beta 2 Released
  6. ZFS & Libdvdcss Should Soon Be In Debian
  7. Ubuntu 15.04 Now Under Final Freeze
  8. EXT4 In Linux 4.1 Adds File-System Level Encryption