Michel DÃnzer 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 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.
Actually I did use oprofile when I did the AGP 1x and PCI gart tests (with an 9000pro AGP and forced PCI mode). I didn't submit the results because they looked uninteresting - glxgears still didn't use really much cpu time, it just was 10 times slower...
oprofile agp 1x (not sure which parameters would be best to use with oprofile though):
You'll probably want to profile the kernel. That's where the actual hardware access happens, so that's likely to be the place where the extra time is spent. oporfile might also /not/ show anything useful. If the extra time is spent waiting for an interrupt from the hardware, it won't show up in CPU_CLK_UNHALTED time. :)
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
