From: Ian R. <id...@us...> - 2003-12-04 19:10:19
|
Roland Scheidegger wrote: > Michel D=C3=A4nzer wrote: >> On Thu, 2003-12-04 at 11:48, Mike A. Harris wrote: >> >>> THe first step to me, would be to oprofile things, and find where the= =20 >>> bottleneck is, then try to determine why. >> >> Good idea, but beware that the gprof output was rather confusing when = I >> first saw this problem, the time would appear to be spent in random 3D >> driver functions when in fact it seemed to be waiting for the hardware >> most of the time. oprofile may do a better job there, but you've been >> warned. >=20 > Actually I did use oprofile when I did the AGP 1x and PCI gart tests=20 > (with an 9000pro AGP and forced PCI mode). I didn't submit the results=20 > because they looked uninteresting - glxgears still didn't use really=20 > much cpu time, it just was 10 times slower... >=20 > oprofile agp 1x (not sure which parameters would be best to use with=20 > oprofile though): You'll probably want to profile the kernel. That's where the actual=20 hardware access happens, so that's likely to be the place where the=20 extra time is spent. oporfile might also /not/ show anything useful.=20 If the extra time is spent waiting for an interrupt from the hardware,=20 it won't show up in CPU_CLK_UNHALTED time. :) |