On Wed, Feb 22, 2012 at 09:40:18AM -0500, Adam Jackson wrote: > On Tue, 2012-02-21 at 16:35 -0700, Michal Jaegermann wrote: > > > This particular one is a 64-bit (albeit quite old) processor: > > > > vendor_id : AuthenticAMD > > cpu family : 15 > > model : 5 > > model name : AMD Opteron(tm) Processor 142 > > stepping : 1 > > cpu MHz : 1600.062 > > cache size : 1024 KB > > > > on a board with 2GB of a physical memory. I know some machines around, > > and doing useful job, where this is a quite powerhouse in a comparison. > > When forced with LIBGL_ALWAYS_SOFTWARE=1 gnome shell was taking all the > > time between 94% and 96% of CPU and a response latency for a keystroke > > or a mouse movement was in a order of few seconds. > > Shot in the dark here, but with the LIBGL_ALWAYS_SOFTWARE=1 force in > place, try an xorg.conf that looks like this: > > Section "Device" > Identifier "radeon" > Driver "radeon" > Option "NoAccel" > EndSection First of all results do not seem to depend at all if with gnome-session-3.3.5-2.fc17.jx I am using mesa-...-8.0.1-1.fc17.jx or mesa-...-8.0.1-1.fc18 drivers and libraries. If anything a CPU usage and latencies seem to be a tad higher with "8.0.1-1.fc17.jx" but differences are so minimal that this is not likely significant. Dropping such config fragment as above into /etc/X11/xorg.conf.d does change the situation somewhat. Starting with /usr/libexec/gnome-session-check-accelerated-helper not segfaulting anymore. As a result after a very long wait a "standard" gnome shell session does show up without a need to force it with LIBGL_ALWAYS_SOFTWARE=1. A gnome-shell CPU usage also goes down from 96% to something like 85% (after a longer period of a complete inactivity it may even drop to something like 20% but a single keystroke somewhere sends this immediately back to the previous levels). Input latencies are somewhat decreased, so you will likely catch yourself before pushing that power switch to recover a "crashed" machine, but are still way beyond what can be remotely acceptable. If booting 3.3.0-0.rc4.git1.4.fc17.x86_64 kernel (the latest one for F17 from koji) instead 3.3.0-0.rc4.git0.1.fc18.x86_64 then a CPU usage maybe further drops to 82-83%, which is hard to tell as that may depend to is happening on a screen even if I tried to behave the same way in all cases, but an overall "feel" does not really change. In summary this is deep into a "dancing pig" teritory; no question of dancing well but one marvels that she is dancing at all. > That kind of latency just doesn't make sense unless EXA is trying to > keep pixmaps in vram, which will be a net loss with llvmpipe since we'll > need to copy them back out of vram all the time, which is unbearable. I am afraid that I am not qualified to sensibly discuss underlying mechanisms. I can only report what I see. In this thread mwesten@xxxxxxxxxxx wrote "the processor gets pegged at 100% continuously and it's not usable". I am not sure what was the hardware. I wonder if turning off acceleration changes anything to him. Michal -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
