kernel 2.6.9-rc2-mm2 vs glxgears

[Dave Airlie]

It may be the missing pci_enable_device line that I patched into
Linus's tree, Andrews tree may not have it yet...

If we don't do pci_enable_device, interrupts don't work anymore in -mm
trees if you don't enable the device..

Dave.

On Wed, 29 Sep 2004 00:21:41 +0200, Felix Kühling <fxkuehl at gmx.de> wrote:
> 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 |
> 
> 
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg
>