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