kernel 2.6.9-rc2-mm2 vs glxgears

Tue Sep 28 19:10:56 PDT 2004

> And so I'm stuck at some default that gives about 10 fps then?
> 
> And where can this patch be obtained?

I've no idea if it was in -rc2 or not .. or if -mm has picked it up I
suspect Andrews tree should have it,  again I don't track Andrews tree
and don't fix bugs in it, if you can reproduce this with
linux-2.6.9-rc2 or linux-2.6.9-bk then I'll spend some time worrying
about it..

Andrews tree is unstable and is not meant to be used in production
environments...

Dave.
> 
> 
> >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
> 
> --
> Cheers, Gene
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> 99.26% setiathome rank, not too shabby for a WV hillbilly
> Yahoo.com attorneys please note, additions to this message
> by Gene Heskett are:
> Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
>