https://bugs.freedesktop.org/show_bug.cgi?id=36596

--- Comment #1 from Jason Cassell bluesloth600@gmail.com 2011-04-25 17:24:17 PDT --- Created an attachment (id=46073) --> (https://bugs.freedesktop.org/attachment.cgi?id=46073) Xorg log

https://bugs.freedesktop.org/show_bug.cgi?id=36596

Jason Cassell bluesloth600@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #46074|application/octet-stream |text/plain mime type| |

https://bugs.freedesktop.org/show_bug.cgi?id=36596

Jason Cassell bluesloth600@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #46072|application/octet-stream |text/plain mime type| |

https://bugs.freedesktop.org/show_bug.cgi?id=36596

--- Comment #4 from Jason Cassell bluesloth600@gmail.com 2011-04-28 16:36:31 PDT --- (In reply to comment #3)

Does that involve wobbly windows or any other effects?

It's the same problem with and without wobbly windows.

One thing I noticed with wobbly windows is that sometimes (but not every time) when the framerate goes back to normal, they'll wobble very fast, like they're trying to "catch up". It looks like it's trying to render all the frames, but some of them just show up late, like something got delayed in a buffer somewhere. I only notice that with wobbly windows, but that might just be because the wobbling makes the phenomenon easier to see.

Did you double-check that enabling LLVM actually worked?

The configure script output says it's using llvm, and "llvm" appears a lot in the build log. I don't know if there's anything else to check.

If that's not the problem, and if the slowness coincides with high CPU usage, a profile from sysprof or oprofile might give some ideas.

The slowness coincides with very low CPU usage. According to htop, when it's working fine, compiz uses from 5% to 16% CPU to move windows around, depending on the window and whether they're wobbly. When it's slow, compiz's CPU usage is 0.0%, and the CPU usage of everything else combined is less than 2%.

This is on a dual core 2 GHz CPU, probably throttled back to 800 Mhz, but I don't know for sure because I wasn't running conky.

htop refreshed every 2 seconds. Sometimes a refresh would make compiz freeze for a fraction of a second, but most of them didn't.

Would it be useful to profile something anyway?

BTW, I should have mentioned that I have to boot with the "noirqdebug" kernel parameter, otherwise the kernel will sometimes disable the Radeon's IRQ saying "irq 19: nobody cared" (the exact message is no longer in the logs). Once the IRQ was disabled, everything still worked, but more slowly.

I also have scrolling performance problems in compiz, but compiz is infamous for causing things like that, so I'm guessing it's a different bug, and I'll worry about it later.

https://bugs.freedesktop.org/show_bug.cgi?id=36596

--- Comment #6 from Michel Dänzer michel@daenzer.net 2011-04-29 02:06:53 PDT --- (In reply to comment #4)

The slowness coincides with very low CPU usage.

If sync to vblank is enabled in the compiz configuration, does disabling that help? If not, does

Option "EnablePageFlip" "off"

and/or

Option "SwapbuffersWait" "off"

in xorg.conf help? (Verify in Xorg.0.log that the options are taking effect)

Would it be useful to profile something anyway?

sysprof or oprofile won't be useful. If none of the above helps, it might be possible to find out where compiz is blocking with something like perf, but I don't know how offhand.

BTW, I should have mentioned that I have to boot with the "noirqdebug" kernel parameter, otherwise the kernel will sometimes disable the Radeon's IRQ saying "irq 19: nobody cared" (the exact message is no longer in the logs). Once the IRQ was disabled, everything still worked, but more slowly.

Hmm, the radeon IRQ not working reliably might explain at least some of your symptoms. FWIW, can you also attach the dmesg output, at least the lines related to agp/drm/radeon?

https://bugs.freedesktop.org/show_bug.cgi?id=36596

--- Comment #8 from Jason Cassell bluesloth600@gmail.com 2011-04-29 22:03:01 PDT --- Created an attachment (id=46180) --> (https://bugs.freedesktop.org/attachment.cgi?id=46180) dmesg output

https://bugs.freedesktop.org/show_bug.cgi?id=36596

--- Comment #10 from Jason Cassell bluesloth600@gmail.com 2011-05-06 23:29:03 PDT --- (In reply to comment #9)

Really sounds like the GPU IRQ doesn't work (reliably). Do the numbers on the radeon line in /proc/interrupts still increase when the problem occurs?

Not a lot. When everything's working, moving wobbly windows involves hundreds of interrupts. When it's at 2 fps, there are only a few, at most. Possibly none.

Maybe try some IRQ related kernel debugging options as applicable, to see if any of them works around the problem.

noapic didn't make any difference.

I can't make the "irq 19: nobody cared" problem happen any more. I don't remember what kernel version I had last time it happened, but with 2.6.38.5 at least, it's not happening for me anymore (so far). When it was happening, irqpoll and irqfixup didn't help.

Debian sid just went through a lot of upgrades. I now have xserver 1.10.1 and llvm 2.8. Yesterday I did a git pull and rebuilt Mesa again. The performance problem's still there.

My hunch, based on my immense lack of knowledge of video drivers and GPUs, is that when things slow down, it's because textures are being moved around in memory. When I rotate the cube in compiz to go to another desktop, sometimes it stutters a bit, as if the texture for the other desktop isn't in the GPU's memory yet, or something. When I resize a window, the newly sized window is a new texture, and something needs to be done with that new texture which apparently takes 5 seconds and keeps the GPU too busy to do much else.

You probably shouldn't listen to me though, since I'm just guessing and I don't really know how anything works.

https://bugs.freedesktop.org/show_bug.cgi?id=36596

--- Comment #12 from Jason Cassell bluesloth600@gmail.com 2011-06-05 21:40:24 PDT --- (In reply to comment #10)

I can't make the "irq 19: nobody cared" problem happen any more.

I was wrong, it still happens. I just don't know how to trigger it anymore.

When IRQ 19 is disabled, compiz runs at 2 fps all the time. glxgears in compiz reports about 300 fps, but most of those frames don't actually make it to the screen. glxgears in openbox runs normally at about 40 to 50 fps. Actually, most things seem fine in openbox, except xterms run slowly.

I'll go ahead and attach the actual error message, I guess. I suspect it might have more to do with the kernel or the hardware than mesa, but I don't know.

https://bugs.freedesktop.org/show_bug.cgi?id=36596

--- Comment #14 from Tomasz P. son_of_the_osiris@interia.pl --- is it still an issue with current mesa?

https://bugs.freedesktop.org/show_bug.cgi?id=36596

GitLab Migration User gitlab-migration@fdo.invalid changed:

What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|NEW |RESOLVED

--- Comment #16 from GitLab Migration User gitlab-migration@fdo.invalid --- -- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/335.