Re: [Dri-users] Status of Savage Driver

[Robert S. K. <rs...@ds...>]

Felix Kühling wrote:
>> Just to see how things were going and perhaps isolate some more, I 
>> started up the x server at that point and am experiencing the high x 
>> load again.  So it would seem that this is something in the 2D driver, 
>> or something in the config I'm using.  I can get back by moving my old 
>> modules back into /usr/X11R6/lib/modules, so I was able to test a bunch 
>> of configurations last night.  I wasn't able to get my CPU back down to 
>> where it is with my stock install though.
>>     
>
> That's odd.
>
>   
Perhaps I didn't explain that well.  By replacing the modules folder I 
can get back to where I started.  What I haven't figured out is if I 
could make the newly compiled CVS version of the server perform as well 
as my stock version.
> Which desktop environment / window manager are you using? Top updates
> fine here with Gnome/Metacity/GnomeTerminal.
>
>   
I use KDE, but it doesn't really matter to me.  MythTV takes over the 
whole UI and there are many other m;yth users who who use really light 
WMs like FVWM, or ICE, etc.  I'll try another one if I can't make this 
one work for me.
> I can't think of any important settings for 2D performance in host.def,
> except maybe compiler options. But I guess most CPU time is spent in
> busy waiting loops. So we're probably doing something different with the
> 2D engine. One thing is that the COB (command overflow buffer) was made
> bigger for better 3D performance. While this should make 2D acceleration
> more efficient too, it may at the same time lead to more CPU overhead in
> busy waiting loops. As for Xv, you can't really compare the old and the
> new implementation. It is expected that smooth scaling takes longer in
> the hardware. Busy waiting makes this horribly inefficient because it
> stalls the CPU at the same time.
>   

Is there anything that I could do to eliminate/minimize the busy waiting 
going on?  Or even know that is the source of my problems?  One of the 
things that stopped me from looking into this earlier is that I didn't 
know where/how to start when it comes to debugging a running driver.  
Stopping and starting the x-server loads of times makes the 
develop/code/test cycle quite long and hard to follow as you work though 
an issue.

Rob