On Wed, Feb 22, 2012 at 8:42 PM, Michal Jaegermann <michal@xxxxxxxxxxxx> wrote: > 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. What is your screen resolution? Single or dual monitor setup? -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
