777 freezes and FPS loss

[biloute974]

Hello,
I come to share with you an amazing thing I've seen on Fg in 2016.1.0
release. Another person has reached the same conclusion as me with the
same version of FG, both using a 777 Seattle.
We took off from TFFF to land at LFLL. For my part, my cruising altitude
was 35,000 feet. I found that, more I climbed in altitude, more I was
losing FPS. Initially I had 60 FPS and more than 35000 feet 22-25 FPS.
During the flight, I went down to 9,000 feet to see if the FPS went up,
in vain. I decided to go up to 35,000 feet for the rest of the flight.
My friend, stole 9,000 feet at 60 FPS all along. Just before he made the
same flight but gaining altitude in steps and it also lost FPS.
I should point out one thing, it has accelerated the simulation speed
and sometimes handed over to normal speed for this test.
On arrival, my friend, flying at 9000 feet, was still 60 FPS and i, i
had no more than 15 FPS.
In summary, during this test, we made the same observation: the higher
you go, more you lose FPS and we not recover if we descend to an
altitude of 9000 feet.
I give you my hardware configuration:
- Intel Core i5 4690 (3.5GHz)
- 16 GB of DDR3 RAM
- Nvidia GTX970 with 4GB GDDR5
- FG 2016.1.0 updated this afternoon (12 january)


---------------------------------------------------


Friend's view point (Xavier, usually AF2222).

This seems to be fully confirmed.


Linux Mint mate 1.6.1.
I7
FX 965.


FG Compilation 2016/01/12 13H UTC.


B77 200ER Seattle.

Constatation:

If standing FL 90, everything seems to be all right.
If climbing to FL 330, slow but constant fps loose.
On LFLL -> TFFF, about 10 fps remainding when arriving (60 fps at
departure).

This phenomena is present for about 2 monthes (with same aircraft data).
It is fully reproductible.
It is is NOT dependent on simulation rate.
Reloading aircraft restores initial fps rate(but no sound after).
This seems to be dependant only on altitude (or inducted parameters,
like ground speed?).

Best regards.

[wkitty42]

can you reproduce this reliably with the UFO???

[biloute974]

Hi,

with the UFO or another plane no problem, it's appear only with 777.

[Hooray]

you could also disable scenery entirely to troubleshoot this.

In general, this is likely due to the way OSG is paging resources in/out (with some being persistent), including scenery and aircraft textures.

For some more troubleshooting, refer to: http://wiki.flightgear.org/Draw_masks

[Hyde]

See https://sourceforge.net/p/flightgear/codetickets/1823/

Thanks,

[Hooray]

the bug report says that this is related to the Canvas ND framework - and the position trend vector feature, who implemented the "position trend vector" feature and where can we find its code ?

Is it part of fgdata or only available in some custom 3rd party hangars ?

[Hyde]

Horray,

Couldn't you find the code?
It's in the fgdata implemented Gijs on Nove 30, 2015.
You can checkout
git checkout 34b957e63b21f9a70cfdbc0b5011c9b5aa252ca1

[Hooray]

I haven't updated/run FG in months, which is why I am asking for the corresponding links: http://sourceforge.net/p/flightgear/fgd ... 5aa252ca1/

[Hooray]

you can add a return statement to the beginning of the is_true() function to see if the issue disappears if the code is not executed.

Once you have confirmed that it is this code that is causing this, there are other if expressions that you could change - my suggestion would be to add print statements there so that you know what is happening - e.g.:

print("rollDeg > 0.2");
print("rangeNM=",nd.rangeNm());

etc

that will hopefully tell us what is going on - if in doubt, pause the simulator and use the property browser to navigate to the ND MAP and its trend vector child, dump the whole thing to the console (or a file) and post it here

[Hyde]

@biloute974

Could you tell what video card do you use and driver version?

I have two PC,
one has nVidia GeForce GT440 - driver version 358.16
another one has nVidea GeForce GT760 - driver version 361.16

This issue happens on the first PC almost every time but never happens on second PC.

Edit: Don't bother. It happens on second PC too.

[biloute974]

Hi,

i have a Nvidia GTX 760 and the problem persist with a GTX 970 with Nvidia driver 352.63. The problem persist too with driver 340.96 and 346.72 (LinuxMint 17.2).
For information, i replaced navdislay.styles of 2016.1.0 version by a 3.7 version and freeze seem disappear but framerate continue to lose in long flight above FL250.

Yesterday a flight from Lyon to Reunion Island for three hours, I had no freeze but FPS drop after a while on cruise. It seems that the FPS drop appears from 25000 feet (not certain).

[Hyde]

Yeah, as I edited previous post, video driver doesn't matter.

I've just specify that the line#913 of navdislay.styles is causing the issue. If it's commented out, issue does not happen. I'm flying on Japan now.

Code: Select all

nd.symbols.trendVector.setData([2,cmd],[512,y1,radius,radius,0,x,-y]);


For FPS, I'm not sure but I don't get that.
Let me see.

[biloute974]

Nice

Problem with FPS appear after one/two hours at cruise altitude.

[Hooray]

@Hyde: I'd suggest to print out the type/size of each variable used in that line, i.e. using typeof()/size() or just debug.dump().
that should tell us if there is anything odd there - maybe, the cmd vector has grown massively or something like that.

Alternatively, pause the simulator and navigate to the property tree node of the Canvas group and inspect that (you can post a screenshot here)

[Hyde]

I'll try tonight.

Thanks.