kernel 2.6.9-rc2-mm2 vs glxgears
gene.heskett at verizon.net
Tue Sep 28 18:29:37 PDT 2004
On Tuesday 28 September 2004 19:47, Dave Airlie wrote:
>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..
And so I'm stuck at some default that gives about 10 fps then?
And where can this patch be obtained?
I don't recall seeing that as a kernel make xconfig option.
>On Wed, 29 Sep 2004 00:21:41 +0200, Felix Kühling <fxkuehl at gmx.de>
>> 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
>> > Noting John Smirls announce on lkml just now, I wonder if I
>> > should be a tester of his new drm?
>> | 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
"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.
More information about the xorg