kernel 2.6.9-rc2-mm2 vs glxgears

[Gene Heskett]

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.
>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.