A question about "Software rendering for gnome-shell"

Adam Jackson ajax at redhat.com
Wed Feb 22 14:40:18 UTC 2012


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.  My guess is that
> more of CPU would be grabbed if only it would be available.  At the
> first moment I thought that the whole thing just locked up and only
> after some delay I realized that I was mistaken.

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

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've run software shell on a slower [1] machine and things were almost
acceptable, but it was an Intel GPU which means the host/video ram
distinction is basically nil.

[1] - Well, synthetically slower, by clamping to the slowest P state.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20120222/a857aa37/attachment.sig>


More information about the test mailing list