kernel 2.6.9-rc2-mm2 vs glxgears

[Felix Kühling]

On Tue, 28 Sep 2004 15:34:36 -0400
Gene Heskett <gene.heskett at verizon.net> wrote:

> On Thursday 23 September 2004 23:39, Gene Heskett wrote:
> >Greetings;
> >
> >Also add a wish that AGP 8x was supported on nforce2 equipt mobo's,
> >but thats not why glxgears, which in previous kernels would start
> > out at 350fps but drop to about 100fps in about a minutes running,
> > is now running at a consistent 10fps effective the 2.6.9-rc2-mm2
> > kernel.
> >
> >Anyone have any ideas why?
> 
> And this continues to be the case for the mm3 and mm4 kernels.
> 
> Some testing here indicates that if I replace *all* the glx stuff with 
> that from MesaLibs, I get around 550 fps, but with 100% cpu going to 
> glxgears.  glxinfo says drm = no

Software rendering on a fast CPU.

> 
> With the 6.8.1 glx stuff installed, glxinfo says drm - yes, and I get 
> 10 fps at 0% cpu, even at full screen, something the MesaLibs stuff 
> can't handle at all.  Other screen actions do seem to be quite snappy 
> even if glxgears is a crippled dog.

Sounds like it could be a problem with frame throttling. My guess is
that interrupts get delayed somehow. The driver uses them to wait for
previous frames to finish rendering. You can try different settings that
don't use interrupts using the environment variable fthrottle_mode, e.g.

fthrottle_mode=0 glxgears	(busy waiting)
fthrottle_mode=1 glxgears	(usleeps)
fthrottle_mode=2 glxgears	(interrupts, the default)

The first one is the best one, performance wise. But it'll result in
100% CPU usage by glxgears. The second one used to throttle the frame
rate to 100 or 50 on Linux 2.4. Linux 2.6 has a higher timer resolution
so it may not be that bad. Interrupts guarantee (usually) good
performance while keeping the CPU usage down.

If it's really related to frame throttling with interrupts, then it
could have different reasons. Either interrupts really get delayed and
the interrupt handler is executed too late. It could also be that the
interrupt handler receives the interrupts promptly but waking up the
waiting applications takes some time, maybe a flaw in the scheduler of
those experimental kernels you're using.

> 
> Noting John Smirls announce on lkml just now, I wonder if I should be 
> a tester of his new drm?
> 

Cheers,
  Felix

| Felix Kühling <fxkuehl at gmx.de>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |