Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Curtis L. Olson wrote: Geoff Reidy writes: The major problem I have with fgfs is that I seem to hit a race condition where all graphics and sound stop for extended periods of time (up to about 30 secs), long enough for autopilot (or me!) to lose control and the plane will always crash. During this time there is no disk access happening or lack of memory, fgfs still uses 99% CPU. Doesn't make any difference whether I use the Mesa files or not. Tried compiling with/without random-objects and threading. Tried running with textures disabled, 16 or 24 bit. It happens after covering a certain amount of terrain. It doesn't matter if I'm flying the A4 or a Cessna I will go down about 1000km north of Sydney, give or take a couple of hundred. Over other parts of the world I usually get further but it always gets me in the end. The program itself never crashes. It's been happening since before version 8.0 came out but noone else seems to have the problem? I had put it down to some gcc3.2 weirdness but others are using it now. I can sometimes precipitate it by switching to tower view, will get a white screen, elevation goes to 4 ft or so, sound stops, oh-oh. This most likely relates to freeing tile memory (i.e. moving old tiles out of the cache and reclaiming their memory.) This was never a fast process and could result in frame rate glitches. When David added random ground cover objects, the problem got *really* bad because the scene graph structure of a tile got a lot larger. David and I worked really hard to optimize that, and I further worked on a partial tile free-er so we could spread the load out over multiple frames. This should have been all fixed by version 0.8.0 so that you should see very little frame rate impact when you cross a tile boundary. What version of flightgear are you running? Regards, Curt. I last did a cvs update and rebuild of plib, simgear and fgfs on 4th October. Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Curtis L. Olson [EMAIL PROTECTED] said: Geoff Reidy writes: The major problem I have with fgfs is that I seem to hit a race condition where all graphics and sound stop for extended periods of time (up to about 30 secs), long enough for autopilot (or me!) to lose control and the plane will always crash. During this time there is no disk access happening or lack of memory, fgfs still uses 99% CPU. Doesn't make any difference whether I use the Mesa files or not. Tried compiling with/without random-objects and threading. Tried running with textures disabled, 16 or 24 bit. It happens after covering a certain amount of terrain. It doesn't matter if I'm flying the A4 or a Cessna I will go down about 1000km north of Sydney, give or take a couple of hundred. Over other parts of the world I usually get further but it always gets me in the end. The program itself never crashes. It's been happening since before version 8.0 came out but noone else seems to have the problem? I had put it down to some gcc3.2 weirdness but others are using it now. I can sometimes precipitate it by switching to tower view, will get a white screen, elevation goes to 4 ft or so, sound stops, oh-oh. This most likely relates to freeing tile memory (i.e. moving old tiles out of the cache and reclaiming their memory.) This was never a fast process and could result in frame rate glitches. When David added random ground cover objects, the problem got *really* bad because the scene graph structure of a tile got a lot larger. David and I worked really hard to optimize that, and I further worked on a partial tile free-er so we could spread the load out over multiple frames. This should have been all fixed by version 0.8.0 so that you should see very little frame rate impact when you cross a tile boundary. What version of flightgear are you running? This discription sounds like a problem that I think I've seen, but haven't tracked down. It seemed as though the tile cache is getting clogged up with unusable entries (this was 2 or 3 months ago btw). IIRC I traced this through to plib to make sure everything was being deleted, but still couldn't verify this was happening. Of course with time, all the tiles for the tower view will be released, and they will require reloading, if tower view is not used. Normally the tiles under the FDM location will be kept current by the code that queries for ground elevation (see end of Main Loop) when the FDM location is not the current view (as in tower view). I don't have time to look right now, but I assume that the code still updates the timestamp for tiles whenever the tilemgr.update() is run as it was a couple months ago. In any case if the capacity of the tile cache is dimminished somehow, maybe with the timestamps getting screwed up, or all the tiles including the one under the FDM location end up with the same timestamp (or the timestamp isn't kept current--so it gets old--by the tilemgr update as mentioned in the previous paragraph), then the tile under the FDM location may get removed when switching to tower view by the reloading that is going on. This would explain the whacky elevation figure. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Dave, On a Geforce3 something, something and a GeForce4 Ti4200 I have observed that FSAA works fine, except when I try to exit FlightGear, my entire machine locks up. On GeForce2, you can't FSAA at resolutions over 800x600 I believe ... and I'll take 1600x1200 over 800x600 FSAA any day ... The Geforce3/4 behavior certainly seems like a driver bug ... Regards, Curt. Dave Perry writes: I posted the following note to the Nvidia linux forum. The issue seems to be an interaction between fgfs and the Nvidia driver. NVIDIA linux foum post: I am a FlightGear enthusiast. Over the past year I have run various kernels with all the released nvidia linux drivers and various versions of FlightGear. My experience separates into two categories: 1. No FSAA affect no matter what value for __GL_FSAA_MODE is exported. In this case, Flight Gear runs with no system lock ups. 2. FSAA affect follows the value of __GL_FSAA_MODE while running FlightGear for some versions but not others. But the system ocasionally locks up when changing active windows or active resolutions. On page 52 of the Nvida Release 25 Notes, the second note indicates that When FSAA is enabled ... the rendering may be corrupted when resizing the window. This is not a minor inconvenience, for it appears to be the cause of complete system lock ups that force hard resets. I can run FlightGear from my Windows XP partition (compiled under Cygwin) at all resolutions and all FSAA settings. So why can't Nvidia get this stability in their Linux drivers. My system is an Athlon XP 1800+ with an Asus A7M266 mother board, 512MB of PC2100 memory and 3 Seagate Baracuda IV (80GB each). My GF3 is an Asus V8200 Deluxe. My Linux is a RH7.3 with recent up2date, but I am running a 2.4.19 kernel compiled from tarball. This kernel has the patch for the speculative cache conflict also mentioned in the Nvidia docs. The behavior described is similar for either the 1.0-3123 or the 1.0-2960 drivers. I always install Nvidia drivers from the source RPMS using the --rebuild switch so that they for sure match the current kernel headers, etc. What is wierd is that FlightGear 8.0 (recent stable release) runs with no FSAA no matter what value I export for __GL_FSAA_MODE and therfore runs w/o crash. However, the CVS version 0.9.0 runs with FSAA ok with depth 16 and 1600x1200 or 1280x1024. With depth 24, there is no FSAA at 1600x1200 (thus stable runs), but there is FSAA at 1280x1024 resolution. In order to switch from the default 800x600 startup window to a 1600x1200 window, I first must cycle the resolutions (ctrl-alt-+) and then resize the window. When I use the normal exit option from fgfs, occaionally the system hard locks when i click on the yes box. With depth 16, and any resolution, (1600x1200, or 1280x1024), I must disable the splash screen, or the system locks up 100% of the time when running FlightGear with FSAA enabled. This is clearly an Nvidia driver bug! Are others having similar issues with complex applications? - Frustrated Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Curtis L. Olson Geoff Reidy writes: The major problem I have with fgfs is that I seem to hit a race condition where all graphics and sound stop for extended periods of time (up to about 30 secs), This most likely relates to freeing tile memory (i.e. moving old tiles out of the cache and reclaiming their memory.) This was never a fast process and could result in frame rate glitches. When David added random ground cover objects, the problem got *really* bad because the scene graph structure of a tile got a lot larger. David and I worked really hard to optimize that, and I further worked on a partial tile free-er so we could spread the load out over multiple frames. This should have been all fixed by version 0.8.0 so that you should see very little frame rate impact when you cross a tile boundary. What version of flightgear are you running? The same thing happens for me with both Cygwin gcc 2.95.2 and MingW gcc 3.2 both using Doug Lea's malloc routines which I believe is what most Linux distributions use CVS version of Cygwin Implemeting the thread support seems to make this even worse but this is a totally unscientific observation FWIW This is bad enough so that any flight covering more then 1000km or so is futile for me as once the condition starts it reoccurs quite frequently Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Norman Vine writes: The same thing happens for me with both Cygwin gcc 2.95.2 and MingW gcc 3.2 both using Doug Lea's malloc routines which I believe is what most Linux distributions use CVS version of Cygwin Implemeting the thread support seems to make this even worse but this is a totally unscientific observation FWIW This is bad enough so that any flight covering more then 1000km or so is futile for me as once the condition starts it reoccurs quite frequently Norman, It might be worth verifying that my partial tile free-er routine is actually running. If it's not running or is being bypassed some how, then the condition you are reporting is very understandable. If it is being run, then it's not doing it's job correctly and should be looked into. You can also tune how much of the tile is deleted per frame. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Curtis L. Olson writes: Norman Vine writes: The same thing happens for me with both Cygwin gcc 2.95.2 and MingW gcc 3.2 both using Doug Lea's malloc routines which I believe is what most Linux distributions use It might be worth verifying that my partial tile free-er routine is actually running. If it's not running or is being bypassed some how, then the condition you are reporting is very understandable. If it is being run, then it's not doing it's job correctly and should be looked into. You can also tune how much of the tile is deleted per frame. I have twiddled the amount freed each time before but I see the code has changed a little since the last time I tried this. FWIW - I ended up assuming that my poor little 256 meg machine just wasn't big enough to run FGFS anymore under Windows as it appears to be memory related disk thrashing that is killing me. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
David Findlay wrote: How do you enable FSAA on Linux with FGFS? Thanks, David For NVidia cards you set the environment variable __GL_FSAA_ e.g. export __GL_FSAA_=4 fgfs will give 2x2 on a Geforce 2. All the options are listed at http://download.nvidia.com/XFree86_40/1.0-2960/README.txt see APPENDIX E. Works with pretty much any OpenGL app. Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Geoff wrote: I was getting lockups in some games and fgfs before making my memory timings a bit more conservative, though it had passed memtest86 previously. Haven't had a lockup for weeks now. Interesting. You are speaking about the timings of the main memory, correct? Did the problems you had beforehand only occur with FSAA on or regardless of FSAA? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Wolfram Kuss wrote: Geoff wrote: I was getting lockups in some games and fgfs before making my memory timings a bit more conservative, though it had passed memtest86 previously. Haven't had a lockup for weeks now. Interesting. You are speaking about the timings of the main memory, correct? Did the problems you had beforehand only occur with FSAA on or regardless of FSAA? Bye bye, Wolfram. I had selected turbo in the bios as I have good quality ram. Lockups were not related to fsaa. Symptoms were pretty strange - fgfs would trigger it randomly, povray would do it on one particular scene. A couple of other programs would also cause it. Lockups were hard and neccesitated a reboot with the reset button. I thought it might have been the Athlon agp bug but upgrading the kernel didn't help. Then I tried disabling the turbo option. I guess to be scientific I should turn it back on to check... Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)
Dave Perry wrote: My system is an Athlon XP 1800+ with an Asus A7M266 mother board, 512MB of PC2100 memory and 3 Seagate Baracuda IV (80GB each). My GF3 is an Asus V8200 Deluxe. My Linux is a RH7.3 with recent up2date, but I am running a 2.4.19 kernel compiled from tarball. This kernel has the patch for the speculative cache conflict also mentioned in the Nvidia docs. The behavior described is similar for either the 1.0-3123 or the 1.0-2960 drivers. I always install Nvidia drivers from the source RPMS using the --rebuild switch so that they for sure match the current kernel headers, etc. What is wierd is that FlightGear 8.0 (recent stable release) runs with no FSAA no matter what value I export for __GL_FSAA_MODE and therfore runs w/o crash. However, the CVS version 0.9.0 runs with FSAA ok with depth 16 and 1600x1200 or 1280x1024. With depth 24, there is no FSAA at 1600x1200 (thus stable runs), but there is FSAA at 1280x1024 resolution. In order to switch from the default 800x600 startup window to a 1600x1200 window, I first must cycle the resolutions (ctrl-alt-+) and then resize the window. When I use the normal exit option from fgfs, occaionally the system hard locks when i click on the yes box. With depth 16, and any resolution, (1600x1200, or 1280x1024), I must disable the splash screen, or the system locks up 100% of the time when running FlightGear with FSAA enabled. This is clearly an Nvidia driver bug! Are others having similar issues with complex applications? - Frustrated Dave Here fsaa works fine in 16bbp at 1280x960 or 24bpp at 800x600. Higher res at 24bpp and fsaa doesn't enable. I think this is the drivers way of telling me I don't have enough video memory. If I start at 800x600 and resize the window I'm down to about 1 frame/sec fsaa or not. Running the same kernel 2.4.19 on Mandrake 8.2. XP2000 on ASUS A7V333 and GF2 32MB. Latest NV drivers built from source RPMs. All compiled with gcc3.2. FSAA works with most of my openGL stuff including quake3. I was getting lockups in some games and fgfs before making my memory timings a bit more conservative, though it had passed memtest86 previously. Haven't had a lockup for weeks now. One weird thing I have have noticed, and I'd be interested if you see the same thing: When you install the drivers it renames some Mesa files, e.g. /usr/X11R6/lib/libGL.so.1.3.403 becomes /usr/X11R6/lib/xxx.libGL.so.1.3.403.RPMSAVE 1) If I compile and run at this point I see fgfs using about 75% CPU and X using the rest. 2) If I reinstate the Mesa files, recompile and run fgfs gets 99% of the CPU and I get significantly better framerates. ldd (for case 2) shows that it's using /usr/X11R6/lib/libGLU.so.1.3.403 which is from Mesa and is not renamed by nvidia, and /usr/lib/libGLcore.so.1.0.3123 which belongs to nvidia, and /usr/X11R6/lib/libGLwrapper.so.0.1.6 which belongs to XFree. From memory I think ldd showed the same files for case 1, it only matters which files are there at compile time. The major problem I have with fgfs is that I seem to hit a race condition where all graphics and sound stop for extended periods of time (up to about 30 secs), long enough for autopilot (or me!) to lose control and the plane will always crash. During this time there is no disk access happening or lack of memory, fgfs still uses 99% CPU. Doesn't make any difference whether I use the Mesa files or not. Tried compiling with/without random-objects and threading. Tried running with textures disabled, 16 or 24 bit. It happens after covering a certain amount of terrain. It doesn't matter if I'm flying the A4 or a Cessna I will go down about 1000km north of Sydney, give or take a couple of hundred. Over other parts of the world I usually get further but it always gets me in the end. The program itself never crashes. It's been happening since before version 8.0 came out but noone else seems to have the problem? I had put it down to some gcc3.2 weirdness but others are using it now. I can sometimes precipitate it by switching to tower view, will get a white screen, elevation goes to 4 ft or so, sound stops, oh-oh. Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
