May 17th 2010, 9:15 PM local time, Santiago de Chile.
This has been a day plenty of good news in the software side of things. For one, the KDE 4.4 migration in Debian Squeeze seems to be mostly complete and SC version 4.4.3 is in testing now, despite having been released by the upstream providers only about a little more than a week ago. I downloaded and installed the packages earlier this morning (blessed be aptitude) and I've seen only satisfying results so far — not to mention that the improvements to the Oxygen widget set and windeco are...uh...OHHHH SHIIIIINYYYYY!!!
*Ahem*, in any case, I've decided to set up (again) a little experiment with kernel modesetting support for my ATI RS780 (r6xx-based) and this HP laptop. Linux 2.6.34 was, according to my sources, released yesterday with lots of performance improvements in that area. I have, as usual, the latest DDX (radeon), DRM and Mesa sources from the git repositories. Right now I'm copying my 2.6.33-tuxonice (188.8.131.52) tree, cleaning it and patching it to prepare a 184.108.40.206 build. The weather is pretty cold and I've got an annoying stomachache which I'm fighting with the Power of Tea. I hope to have luck...with the kernel, I mean, not the stomachache, although I guess that's also important for a complete and comfortable user experience.
For what is worth, I'm not using a Tux-On-Ice patch for 2.6.34 since there's no such officially released yet — I only want to try KMS and go back to 220.127.116.11 for production until I hear news from TOI, unless things go really wrong and I simply decide 2.6.34 is not for me, like I once did with 2.6.29 and 2.6.30.
27 minutes after starting make-kpkg, I have obtained a fresh 2.6.34 kernel with a delicious vanilla smell. I'll now put it in the oven — er, I mean, install it with dpkg, recompile the radeon DDX with KMS support and reboot.
*end of record*
While things didn't go as well as I expected, I can assure that KMS' performance with this ATI RS780 improved a lot since Linux 2.6.33, especially when dragging windows around with a compositing window manager. Something that really amazes me is the shorter delay (less than 1 second now, used to be between 2 and 3 seconds) in resuming from suspend-to-RAM.
The problem here is that OpenGL clients still suffer a lot of performance loss under a compositing manager such as KDE 4.4.3's Kwin — which they generally don't with UMS, which only causes flickering — making Frogatto's camera motion jerky and annoying. This is not a Good Thing™ (particularly because of a greater reason I'll eventually explain in detail) and this means that if I wanted to use Frogatto with KMS I'd have to disable compositing with the handy keyboard shortcut...in other words, not different to how I use it with UMS. No gain for some substantial loss.
There's still some performance loss with KMS and no compositing. It isn't very noticeable in Frogatto most of the time, but I've been using an old eduke32 build with an old version of the High Resolution Pack as a test case for Mesa for quite a while now. Framerate drops from between 70 and 90 FPS (UMS) to between 30 and 50. It's still acceptable, but not optimal and this is not even a worst-case scenario.
I thought for a moment that this loss could be caused by a couple of options I left set in my xorg.conf from UMS, namely ClockGating and DynamicPM, so I disabled them and restarted X. Again, no differences, except for a little warning that appeared in the kernel logs with no further explanation.
You have old & broken userspace please consider updating mesa
Okay, wait, how can the userspace support be “old & broken” and yet it works at acceptable performance? Then again, it's partially right in complaining because I haven't recompiled mesa (not that I really should, probably) in a couple of days. So let's try again with a newer mesa.
*end of record*
Here we go, with a current version of mesa's source code from the git repository. Everything looking the same again. No performance improvements or extra losses. Again, I use eduke32 as a stress testing suite for lack of something better.
So...wait...WHOAH...THE COLORS MAN, THE COLORS!! IT'S SO BEAUTIFUL...IT'S...IT'S...
I have no fucking idea of what happened. I don't know if the GPU (or the display?) got hyperstimulated or it was just my eyes, or my brain, but after rebooting from the aforementioned...crashed...system (which didn't react to any magic sysrq sequence for a change), the GRUB menu background (blue) was blinking so quickly it was making me dizzy.
My theory is that yes, the GPU got hyperstimulated and needed to cool down for a few seconds, just like my eyes. In any case, the KMS kernel in question has been destroyed and I'm back on 18.104.22.168 with Tux On Ice and using drivers in UMS mode. Oh...the colors...there are no words, screenshots or photos which could demonstrate my point. IT WAS SO FREAKIN' COOL THAT I'm currently wondering if it permanently damaged my hardware or it's just one of those "as long as it doesn't happen again we're okay" things. O_o The effect was pretty hypnotic despite looking like a still screen going brighter and brighter...
There's naturally nothing in the kernel logs hinting to what happened. I'd say it was a hardware failure, maybe caused by a corrupted firmware image making it past the defenses. </wildguessing> In any case I don't think I want to try KMS for a while...at least not until I have a whole laptop (or eyes) to spare.