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(a)verizon.net 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