A question about "Software rendering for gnome-shell"

[Michal Jaegermann]

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 at 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