Created attachment 46072 [details] lspci -v With compiz, making a new window or resizing a window makes the framerate drop to 2 fps for about 5 or 6 seconds. Running conky makes the frame rate that low most of the time, alternating with brief moments of decent performance. With a more traditional window manager (openbox), a lot of programs (including xterm) freeze briefly every time conky redraws itself, so it seems like that particular problem is not entirely a Mesa bug. Things run smoothly with the fbdev Xorg driver. I tried compiz with the --no-fbo option once, and the framerate stayed at 2 fps until I rebooted. Restarting X didn't help, I actually had to reboot. With the classic Mesa drivers, compiz would sometimes take a long time to render a few frames, but not nearly as often as it does now. I've had this problem with the Debian Mesa packages since they switched to gallium, and with git master (as of yesterday) built with and without --enable-gallium-llvm. I run Debian sid on a Dell Inspiron 1721 with an integrated Radeon X1270.
Created attachment 46073 [details] Xorg log
Created attachment 46074 [details] glxinfo output
(In reply to comment #3) > With compiz, making a new window or resizing a window makes the framerate drop > to 2 fps for about 5 or 6 seconds. Does that involve wobbly windows or any other effects? > I've had this problem with the Debian Mesa packages since they switched to > gallium, and with git master (as of yesterday) built with and without > --enable-gallium-llvm. Did you double-check that enabling LLVM actually worked? 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.
(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.
Created attachment 46146 [details] /proc/interrupts
(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?
Compiz's sync to vblank option was already off. Turning it on hung compiz, and I had to switch to a VT and kill -9 it. That reminds me, with the gallium drivers I have to have vblank_mode set to something in .drirc, otherwise everything using OpenGL hangs. With the classic drivers I didn't even need a .drirc. vblank_mode is currently set to 1. Turning off EnablePageFlip and/or SwapbuffersWait doesn't help.
Created attachment 46180 [details] dmesg output
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? Maybe try some IRQ related kernel debugging options as applicable, to see if any of them works around the problem.
(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.
(In reply to comment #10) > (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. That probably explains the slowness, as the drivers heavily rely on the IRQ for tracking GPU progress processing commands. With no interrupts coming in, things will time out all over the place. The question now is why there are no interrupts coming in...
(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.
Created attachment 47579 [details] Disabling IRQ 19 error message and call trace
is it still an issue with current mesa?
On Wed, Jan 09, 2013 at 11:55:40AM +0000, bugzilla-daemon@freedesktop.org wrote: > --- Comment #14 from Tomasz P. <son_of_the_osiris@interia.pl> --- > is it still an issue with current mesa? I tried compiz with the mesa currently in Debian Sid (8.0.5-3), and it worked fine until I tried to run celestia. Celestia hung before it rendered anything and had to be killed, and compiz got stuck at 2 fps or less. I logged out and back in, and compiz worked fine again. So, it's better, but still has problems. I'm tempted to say it's a quirk of the Inspiron 1721 (which isn't my main system anymore, btw), but I don't really know enough to speculate.
-- 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.