| Summary: | composite + radeon + glxinfo = 1h 90%CPU | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Dirk Salewski <mail> |
| Component: | Demos | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | CC: | erik.andren |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
xorg.conf
Xorg.0.log (working, without Composite) Xorg.0.log (with Composite, before glxinfo) Xorg.0.log (with Composite, after glxinfo, CPU=100%) Output of glxinfo with Composite enabled Output of glxinfo with Composite disabled |
||
|
Description
Dirk Salewski
2005-08-21 23:05:50 UTC
Created attachment 2976 [details]
xorg.conf
Created attachment 2977 [details]
Xorg.0.log (working, without Composite)
What I forgot to mention: glxinfo is just a bulletproof way to trigger the bug - You might think "just don't use it". Unfortunately there are other programs that do it, too. I wasn't able to compile a list, though, because there's no user interaction required. Sometimes I come back to my desk and CPU=80%. So I can't just stop using glxinfo and expect everything to be alright. Created attachment 2978 [details]
Xorg.0.log (with Composite, before glxinfo)
Created attachment 2979 [details]
Xorg.0.log (with Composite, after glxinfo, CPU=100%)
Created attachment 2980 [details]
Output of glxinfo with Composite enabled
Created attachment 2981 [details]
Output of glxinfo with Composite disabled
I tested this with external radeon modules (not in-kernel). Same effect. Very strange, though: When CPU is near 100% after glxinfo it drops to 3%-10% when running glxgears (can be invisible, hidden, on other workspace). So I'm now able to work when I run glxgears... Just to chime in. This bug is still present in X11R6.9-RC4. As soon as the dri driver gets loaded (triggered by running glxinfo), the whole system becomes extremly sluggish and virtually unuseable. I'm using the latest cvs radeon_dri.so driver (Radeon 7500 in my case). Does this also happen if you don't enable backing store? (In reply to comment #10) > Does this also happen if you don't enable backing store? Short answer, probably misleading: No! Long answer: I got so frustrated with all this eyecandystuff that I started to use icewm again - icewm does not have this sort of problem (the problems occured in xfce4 with transparency, window-shadows and all possible wizardry enabled). Now, when I read Your post I tried it all again - and it seems that I cannot trigger the bug anymore (both with and without backingstore). There's one thing to note, however: I run "conky" and "root-tail", both of which draw directly to the root window. Conky is put into "single buffer" mode, because otherwise it makes root-tail invisible. When I ENABLE backingstore and issue "glxinfo" conky starts to update itself r ea ll y s l o oo o w. So I guess it has to do something with backingstore and improved a bit since my last post. Greetings, Dirk Dirk, are you willing to go back to XFCE to do some more debugging or should we close this bug? Hey Erik, I'd prefer to stay with icewm for now. I have to get some serious work done, and I simply don't have the time for debugging eyecandy at the moment. (Sometimes I think by myself: "Hey, isn't all of this going into the wrong direction, and shouldn't everybody be using wmii by now?") If I ever get into the lucky situation to have the time to tinker with these configfiles again, I will reopen the bug (if it persists). Greetings, Dirk Closing. |
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.