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
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
