<quote who="Keith Whitwell"> > Why do you even care about software rasterization? In normal use the card > basically never does this.
Only because I remember the numbers from when DRI has not been set up properly, and I get suspicious when DRI runs slower than the software rendering. > There is code in the newest r200 driver that uses irq's to do the same > thing that the old busy waits used to, but (see yesterday's thread) there > is a bug & I had to disable it. When that bug is fixed, you should get > good gears numbers *and* low cpu utilization without any env. vars. > I missed that thread, actually... are you talking about the r200WaitForFrameCompletion one, or somewhere else? > >So, I'm looking to understand why the standard glxgears now renders slower > >than software fallbacks used to, and why now when I use R200_NO_RAST I only > >see 50FPS in glxgears > > Because the usleep takes up a longer time than it takes your cpu to draw a > frame of gears via software rasterization. > OK, this makes sense for why it would be limited to 200FPS, but it doesn't explain why R200_NO_RAST now yields 50FPS, does it? I have got the right env var, havent I? (ie R200_NO_RAST makes it do no hardware accel?) J. -- Jan Schmidt [EMAIL PROTECTED] ENOSIG ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
