A question about "Software rendering for gnome-shell"

[drago01]

On Wed, Feb 22, 2012 at 8:42 PM, Michal Jaegermann <michal at harddata.com> 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 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.

What is your screen resolution?
Single or dual monitor setup?