Re: [Flightgear-devel] FSAA frustration continues (Nvidia forum post)

[Geoff Reidy]

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 40000 ft or so, sound stops, oh-oh.

Geoff




_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel