On Tue, 2007-02-27 at 21:59 +0000, Richard Hughes wrote: > Well, I get this: > > CPU: Core Solo / Duo, speed 1662.57 MHz (estimated) > Counted CPU_CLK_UNHALTED events (Unhalted clock cycles) with a unit mask > of 0x00 (Unhalted core cycles) count 860000 > CPU_CLK_UNHALT...| > samples| %| > ------------------ > 12704 82.6330 /usr/bin/Xorg > CPU_CLK_UNHALT...| > samples| %| > ------------------ > 12066 94.9780 /usr/lib/xorg/modules/libfb.so That's pretty well expected. If anything's going to be burning CPU time it's either fb or GLcore. (Or the driver itself when it sits in infinite loops waiting for the command queue to catch up, but that case usually means wedged hardware.) More interesting is knowing which functions it's hitting, if you can get that. Would also like to know whether the same slowdown happens when using Option "ShadowFB". If not then we can assume the slowdown is being caused by a software fallback to something that happens to be in card memory, and there might be a reasonable heuristic for evicting things from card memory when that happens, or just a smarter way to write that routine that hits the bus less. But if it's still slow when shadowfb'd then either it's some particularly naive code, or g-t is just asking us to do a lot of really painful things. > But also I get this (!!!): > > oprofile: using NMI interrupt. > > ================================= > [ INFO: inconsistent lock state ] > 2.6.20-1.2949.fc7 #1 Yow! - ajax -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
