Open-source radeon, drm/radeon and Kernel Mode-setting

The Kernel Mode-setting code in the drm/radeon module of Linux kernel 2.6.32 is disabled by default, and the build-time option to enable it by default is in the Device Drivers -> Staging drivers section for some reason. Nonetheless, I built my first 2.6.32 kernel, installed a newer libdrm and X.org radeon module from upstream, and rebooted.

Although the basics work well and I get a special framebuffer driver taking over all text consoles, this accentuates the problem with the X.org radeon module I mentioned earlier regarding restoration of console status; the first time I switch from the X server console back to text mode, the drm/radeon framebuffer driver takes over and I get some shiny 1280x800 text consoles, which isn't possible with vesafb or radeonfb, which doesn't even support R7xx chipsets.

However, switching from the X server to a text console for the second time invariably resulted in the dreaded, permanent BSS (Black Screen Syndrome) which only occurs occasionally with non-KMS builds of radeon. Additionally, the X server acquires a worrisome habit of locking up when being restarted (say, invoke-rc.d kdm restart), not unlike the non-KMS proprietary fglrx driver from ATI. To make things worse, XRender acceleration seems to not work properly (if at all) with this configuration.

In other words, I reverted to a 2.6.31 kernel to get some work done before building another 2.6.32 kernel with KMS disabled by default plus some other configuration changes.

Rendering performance comparisons and Wesnoth

In Wesnoth, we do not use OpenGL for 2D rendering because many developers and users would not be able to work with it due to the dreaded hardware compatibility issues. I'm not the exception; I both wish and fear that we used OpenGL — although I recall someone mentioning that it may not improve performance a lot. Case in point, there was an ephemeral effort to switch to OpenGL in a mainline SVN branch for a while some years ago. It died.

Wesnoth's gamemap infrastructure allows for animating terrain tiles, units and floating labels. Many things need to be taken into account when updating every animation frame, so if you have many units playing animations at once, and animated terrains such as flags on captured villages, things get a little sluggish if you don't have enough processing power (understatement). Sadly, I'm horribly affected by this inherent problem. Here's a very rough measuring of Wesnoth's (a -O3 build, to be precise) performance with similar game states and different X.org configurations:

<shadowmaster> the maximum with radeonhd and shadow framebuffer is 48 FPS in this game state.
<shadowmaster> with radeonhd and EXA with no XRender-based composition manager is around 40. With radeonhd and EXA and a composition manager it's about 35, and with radeon and EXA and a composition manager it's about 25.
<shadowmaster> and with radeon and no EXA it's about 40. Which means radeonhd wins the contest

This is with a maximized window, that is, around 1280x750.

As a result, in order to continue playtesting IftU, I decided to disable all desktop effects in KDE 4's settings. Sad

Open-source radeon, drm/radeon and Mesa

Ivanovic mentioned to me (again) that the newest revisions of Mesa from the git master branch provide support for ATI R6xx and R7xx chipsets, and work with the 2.6.32 kernel. With very few hopes of getting something usable in return, I decided to download the 7.7 Release Candidate from the Mesa Project's website and try it, along with libdrm and radeon builds without KMS support, and the Linux kernel 2.6.32.

It worked! Well, I don't have the correct software to measure how well it works, but it works:

name of display: :0.0                 
IRQ's not enabled, falling back to busy waits: 2 0
display: :0  screen: 0                            
direct rendering: Yes
[...]
OpenGL vendor string: Advanced Micro Devices, Inc.                             
OpenGL renderer string: Mesa DRI R600 (RS780 9612) 20090101  TCL               
OpenGL version string: 1.5 Mesa 7.7-rc1
[...]

So, how'd I test this thing?

PrBoom (Debian Squeeze's version) achieves around 50 FPS using the OpenGL renderer with a 800x600 window, however, whereas the 2D renderer achieves more than 80 FPS. However, a build of eduke32 achieves as much as 180 FPS with the OpenGL renderer, using the vanilla game data (e.g. no High Resolution Pack).

KDE's OpenGL compositing works fine with some of the most esoteric window effects, although performance is not always the best. Note that both OpenGL and XRender effects hurt XVideo rendering and VLC media player if they are set to lower speeds than “Very fast”; otherwise, the performance impact here is almost negligible except for poor Wesnoth, which achieves at most around 35 FPS with Kwin's OpenGL compositing and today's benchmark game-state; this means that I'll have continue running Wesnoth without composition for now. Thankfully the KDE devs put a hotkey sequence (Shift+ALT+F12) for easily toggling composition into this thing.

In summary, the kernel DRM coders, X.org radeon driver and Mesa developers have done an outstanding work to get this done. I hope it gets better as the Mesa ATI r6xx/r7xx drivers evolve and receive more exposure and testing with more complex OpenGL clients, but for now, this has made my day.