Kernel Mode Setting performance issues

[Bulkley]

With the release of 2.6.32-5 into Squeeze, Kernel Mode Setting is here. It works. For some, KMS the transition is so smooth that they don't notice. Others experience serious performance hits. For me, KMS means fps (as reported by glxgears) is cut in half, video is plagued with hesitations and terminal scrolling proceeds like a mechanical sign with each line flipping down, line by line by line by . . . .. As usual documentation is slow to keep up (at least what I could find) and information has to be filtered out of various forum posts. Phoronix has some of the best reports and forum discussions. Ubuntu and Arch have some.

Questions: Are the problems hardware related? Does KMS put more load on the CPU? Does it use more memory? Does KMS move resource use from the video card to the mobo? Should we prefer /etc/modprobe.d/radeon-kms.conf or /etc/default/grub for initiating KMS?

I came across one developer's comment that the primary effort so far is making it all work and that he will work on speed later. He is probably right.

Does anyone have any KMS tuneup hints? Anyone have good documentation? Any thoughts?

[BioTube]

First, in the words of the main r300g dev, gears is not a benchmark; the radeon module forces VSYNC on in the versions that support it. Second, KMS allows use of all your card's VRAM(UMS is limited to the first 256 MB). Finally, the DRI2 paths will take some time to optimize; you can try 2.6.34 if you want that performance bad enough.

[Bulkley]

First, in the words of the main r300g dev, gears is not a benchmark; the radeon module forces VSYNC on in the versions that support it. Second, KMS allows use of all your card's VRAM(UMS is limited to the first 256 MB). Finally, the DRI2 paths will take some time to optimize; you can try 2.6.34 if you want that performance bad enough.

I knew that the first comment would be that glxgears is not a benchmark. Still, a 50% drop is significant, in my opinion. It shows up dramatically in 3D games which, on my machine, are non-functional with KMS.

Is the problem with the kernel? Or DRI2? Or both? Is the best approach to simply wait?

Here is someone else's experience. So...wait...WHOAH...THE COLORS MAN, THE COLORS!! IT'S SO BEAUTIFUL...IT'S...IT'S... It's a funny read, so enjoy it.

[gradinaruvasile]

Just disable KMS in /etc/modprobe.d/radeon-kms.conf. I installed Squeeze on an older rig (ati 9200 card) and this new kernel+radeon drv killed the card - not only glxgears is at 10% of the former driver, but in 3d apps aswell the performance is appalling. I edited that file, changed the 1 to 0 and the speed is back (but other texture-related issues and stuff remains for 3d games).

[Bulkley]

Just disable KMS in /etc/modprobe.d/radeon-kms.conf. I installed Squeeze on an older rig (ati 9200 card) and this new kernel+radeon drv killed the card - not only glxgears is at 10% of the former driver, but in 3d apps aswell the performance is appalling. I edited that file, changed the 1 to 0 and the speed is back (but other texture-related issues and stuff remains for 3d games).

Yes, your experience is like mine. When I want to play games I turn off KMS as you explain. However, from time to time, Linux takes a big step such as the switch from XF86 to Xorg and Grub to Grub2. These things are always accompanied with a fair amount of growing pains. KMS looks to be one of those major changes. It has come to stay and we need to adjust. In the long run, KMS looks to be a major improvement and we need to learn how to take advantage of it.

What I have been wondering is the possibility that some of the settings we made for UMS (user mode setting or legacy if you prefer) are now interfering with KMS. I'm wondering if there are files or packages that need to be removed. I tried renaming xorg.conf with terrible results; I don't know why. I'm even wondering if I need to reverse some browser settings.

I have been searching google for days for suggestions without much success. I guess, what I am really looking for is a KMS tuneup procedure.

[stevepusser]

Does the kernel boot cheatcode "nomodeset" still work, and does it help?

[emariz]

In my case, using an Intel GMA 4500MHD video device, Gnome doesn't load automatically and the screen flickers if Kernel Mode Setting is enabled. Thus, I disabled it in /etc/modprobe.d/i915-kms.conf, and enable it on every update of the kernel, Xorg or the video driver. It still doesn't work today.
The only issue I've noticed by disabling KMS is that the wallpaper is black after resuming from suspension, and only appears once a window covers ("paints") it.

[llivv]

From what I have gathered so far KMS is all about moving configuration from the system to the kernel.
For X that means the new drmframebuffers that are currently being switched to during boot will most likely be replacing the xserver-xorg-video-yourdriver
And the input drivers are also being rerouted, but at a slower pace ATM
There are also other drivers that are currently being incorporated into the kernel and will eventually be swallowd by the kernel as well.
It's a transition that just takes time, and testing and unstable are not going to be the same as they used to be for a long time..
Just imagine trying to get all the hardware now available, preconfigured automagically in the kernel at boot..
And not just the little desktop lineup either.....
Hopefully, it will be possible to move a stable release out of all this....
I'm keeping my fingers crossed...

[gradinaruvasile]

I added an xorg.conf:

Code: Select all

Section   "Device"
   Identifier   "Device0"   
   Driver      "radeon"
#   Option      "AGPFastWrite" "true"
   VideoRam    65536
EndSection

Section "DRI"
  Mode 0666
EndSection

Section "Extensions"       
  Option "Composite" "Disable"
EndSection

My findings so far:

- I noticed tons of errors in dmesg like :

[ 150.578199] ioUrbanTerror.i:2029 freeing invalid memtype d02e2000-d02f2000

The numbers change in the brackets, after "i:" and so does the memory range and so do the apps that output it (there are ioUrbanTerror, glxinfo sometimes and X most of the time)

- The "nomodeset" parameter doesnt appear to work on its own - changing 1 to 0 /etc/modprobe.d/radeon-kms.conf does work.

I tried some lower-end games on the 9000 (sorry, in the other post i was mistaken about it, its 9000 with rv250chipset) to see its OpenGL capabilities. I tried some ioQuake engine based games - urban terror, smokin guns, billard-gl.
The results are dissapointing: The games run slow and there is an issue with texturing - i mean the textures flicker+change on walls/3d objects. Billard-gl crashes if i click on the video options menu.
With kms enabled the textures are ok, but the mouse input lags badly -- - FPS-wise it seems to be something like the kms-disabled version though, only the mouse input has about 1 sec lag (but its smooth, doesnt bounce - no mouse settings help, be it from the desktop or the game). The same games run perfectly well on another desktop with nvidia card so this has to be video-driver related.

- Overall when kms is disabled, the system is more responsive, windows draw noticeably faster - also glxgears has a score of ~2000 vs the ~1000 when kms is enabled (just informative, i know it is not a true benchmark).

[llivv]

I'm noticing with nouveau, (for several reasons ie: conflicts with nvidia and nv both with kms on and off, the typcial frambuffer and drmframbuffer issues that show up with all the xserver dirviers ATM, etc, etc) That it's EXTREMELY easy to be missing a package or two from the system that is an integral part of the configuration you're trying to optimize...
ie: to get nouveau running (on sid) not only do I need linux-image-2.6.34-1-686 xserver-xorg-video-nouveau libdrm-nouveau1 libdrm2
but also
libdrm-intel1 libdrm-radeon1
bringing with them other deps

These also have to match the xserver packages you are running mainly : xserver-xorg xserver-xorg-core xserver-xorg-input-evdev as a minimum

If your building a minimal xserver install, you have to learn what X needs to get startx or xinit to bring up X.
So that now finding what is changing with each new version becomes "at least" a bit less frustrating ..
Learning how to downgrade your xserver to the last one that worked well for you is also an invaluable skill to have ... especially when you get blank screens..

I'm not using amd64, and I'm certain that reduces complexity as well.... at least from what I read so far.....

I've used glxgears and glxinfo in the past, and fps is good to know as a user, but doesn't provide a devel with any useful debugging data..

To help debian and yourself with X please read the HOWTOs at the x-strike-force-wiki page
http://wiki.debian.org/XStrikeForce
http://wiki.debian.org/XStrikeForce/XserverDebugging
http://wiki.debian.org/HowToGetABacktrace
http://wiki.debian.org/XStrikeForce/ReleaseNotes

[Bulkley]

I've used glxgears and glxinfo in the past, and fps is good to know as a user, but doesn't provide a devel with any useful debugging data..

Exactly. Glxgears shows that my fps with KMS enabled is half of what I get with KMS disabled. That's significant to me, even if it doesn't tell developers anything.

Part of the problem is that there are so many different development teams who have to coordinate (kernel, xorg, mesa, drm, etc) and their output is entering the repos individually which can cause issues. Essentially, you and I and the next guy are testing these things. (That's why Squeeze is called Testing.)

On the ling run, I'm hopeful which is why I am keeping KMS active. The reasoning behind it seems good. The short term fly in the ointment may be summer vacation.

I'd really like to know if there are files or packages which should be removed.

[Bulkley]

Here's a good explanation of the difficulties that developers are having with Linux graphics.
Linux “Graphics Driver Stack” Explained

[Bulkley]

Did anyone notice this:

Does DRI2 suck? No! According to the developers, DRI2 makes simple operations less efficient, like these "benchmarks" below. On the other hand, more complex operations (which will be used in a 3D-intensive application like games) should be more efficient with DRI2.

Ubuntu Wiki

Scroll down most to the way to a a chart benchmarking KMS/DRI2 versus non-KMS/DRI. You will notice that DRI2 compares terribly against DRI1. Mine isn't quite as bad as that but, so far, DRI2 looks like the problem.

[Bulkley]

As BioTube mentioned above, glxgears is a poor test of performance. It is better to make comparisons with a game. For the purpose of this thread I suggest ppracer (Planet Penguin Racer) which is simply un-playable under KMS yet works well with UMS.