Holiday Gift: OpenGL Radeon Performance Goes Up

The R300g and R600g Radeon Gallium3D performance is now up for certain workloads thanks to an important performance fix.

Originating from my article on Thursday about the The Grinch That Stole The Radeon Gallium3D Performance with regard to dramatic drops in OpenGL frame-rates with current Mesa Git master, then Friday's article that noted the offending commits in Mesa causing the performance regressions thanks to the automated bisecting abilities of the Phoronix Test Suite, one day later one of the issues has been addressed.

One of the regressions I noted in the Friday article was for the open-source Nexuiz game and tracked down to being a change related to the Radeon winsys when the management of GEM memory domains was moved out of the drivers and into the winsys. This commit had corrected some Piglit regressions, but to which Marek Olšák "can't explain" why those regressions were fixed. But as the Phoronix Test Suite found, it caused this drop in performance. With Mesa lacking a continuous integration system for performance management (though I've been working on a solution), this regression went unnoticed for three months (Marek committed this change in September during Oktoberfest).

So what Marek has done today is partially reverted the commit. Hitting Mesa Git master today is 93f4e3cb6c1ca303ee1f5c2a2491a8eff33f2633 with a description of:

winsys/radeon: move managing GEM domains back to drivers

This partially reverts commit 363ff844753c46ac9c13866627e096b091ea81f8.

It caused severe performance drops in Nexuiz. Reported by Phoronix.

Tested by me on r300g and by IRC people on r600g.

So this change not only affected the R300g driver (Radeon 9500 through Radeon X1000 series), but also the R600g (Radeon HD 2000 through HD 6000 series) as well. This revert touches about 200 lines of code. I'll be testing it soon to verify the performance has been restored for my test systems.

While it's unfortunate this Radeon performance regression was present for nearly three months, at least it's been reverted in time for the Mesa 8.0 branching.

On the topic of Mesa continuous integration to catch issues like these immediately, I still have plans to setup performance trackers of Mesa/Gallium3D across the major Intel, Radeon, and Nouveau drivers to run benchmarks on a per-commit basis. The infrastructure is in place -- it's been that way since 2009 when I began monitoring the Linux kernel performance on a daily basis as well as Ubuntu packages and more. All of the continuous integration work and performance testing can be done via the Phoronix Test Suite - Phoromatic - OpenBenchmarking.org stack -- even for automatically monitoring changes in the rendered image quality. Wine / CodeWeavers is using it quite successfully too for monitoring their performance on a near-commit basis.

The only issues causing months in not getting around to finalizing these Mesa trackers have been my severe lack of time (that includes even working Christmas) and that constantly running multiple machines with various higher-end graphics cards does consume a bit of electricity that is harder to justify without any corporate backer of the Mesa-tracking project.

Regardless, the Mesa trackers shall come. I might also have some holiday performance gifts to the Linux community in the next couple days.