Excessive VAS usage in P3D V3.4 triggered by OPTIMIZE_PARTS

[RaptyrOne 1,412]

What is the down side to setting the value to zero? Poorer rendering of the aircraft?

[Nuno Pinto 1,397]

I didn't notice any loss of VAS upgrading to 3.4, exactly the opposite. If i had 1.1 - 1.2GB free when cruising now it's not unusual to see values around 1.4GB.

 

I don't use any traffic addons as i fly online exclusively, and no FS2CREW or similar, but i do have an insane library of over 600 airports, vector, freemesh, orbx regions, AS2016, GSX, etc which i never disable under any circumstance.

 

Worst case i've seen was with a 777LR with over 18 hours flying was 500MB free when landing in Melbourne after taking off from Lisboa (~9000nm).

 

3.4 when compared to the original FSX is simply another world in performance and memory management.

[Guest]

Thanks for all the input, will pass info along.  

 

I probably should have provided a more specific testing process to eliminate variables.

 

1.  In prepar3d.cfg, set OPTIMIZE_PARTS=0, turn AI traffic OFF

2.  Delete Shaders folder

3.  Run P3D (display scenario screen, not direct into 3D window), set weather to clear (do not use a weather engine), time of day to noon

4.  Load aircraft and airport of choice (in my case Virtuali's KMEM or KIAD)

5.  Once in 3D view in the VC, do two slow 360 view rotations

6.  Now goto Spot view and do two slow 360 view rotations around the aircraft

7.  Return to VC view and take Note of VAS

8.  Exit P3D

 

Repeat steps 1 to 8, only for step 1 set OPTIMIZE_PARTS=1

 

Also, when reporting VAS make sure you are reporting "Virtual Size" (not "Working Set Size" or "Private Bytes").

 

OPTIMIZE_PARTS=0 can have a performance impact on some aircraft (especially PMDG) while on others it makes no difference.

 

Again, appreciate the input.

 

Cheers, Rob.

[carlito777 712]

 

 

2. Delete Shaders folder

 

My numbers above are based on the exact approach you described. But I didn't set AI to 0 (However, I set the exact same times and dates on both tries so that shouldn't make a difference) and didn't delete the Shaders. Is deleting the shaders a crucial step? If yes, then I can redo the test if that would be helpful for you.

[Guest]

Is deleting the shaders a crucial step?

 

It's an important step for this particular case (as are both VC and spot 360 view rotations), my fault for not being concise at the beginning of this thread, sorry.

 

Cheers, Rob.

[Navigator43 25]

I deleted the camera cfg and it seemed to solve the VAS issue for me. Now I did try optimize parts=0 as well with the camera cfg. I will try putting optimize parts back to 1 and see if that does anything to VAS. But I think it had to do with the Camera cfg

[Guest]

I had deleted my camera.cfg some time ago ... that issue had come up in Beta and I thought was resolved for final release, but perhaps it's tied to the Content installer and not the Client installer.

 

Cheers, Rob.

[odourboy 1,289]

I conducted some tests before I read your specific test process, but I'll report some results anyway: With 737NGX at KEWR with DD city scenery, Optimize parts 0 appeared to save me about 80Mb. I'll try this again with your suggested process.

 

I had some other observations:

1) Transition fro day to dusk seemed to consumed a small amount of VAS (but AI traffic could have been the variable)

2) Turning on cockpit lighting in the NGX consumed a good chuck of VAS, at least 100MB, but it was almost entirely recovered over the next 30 seconds to a minute. If I had been close to the limit, them turned on the cockpit lighting, I'd have had an OOM. (Which I have!)

3) Changing time (day to dusk in my test) using the Time & Season pulldown consumed a good chunk of VAS - maybe 200Mb that did not seem to get recovered. I would say don't ever do this at any time during a flight.

4) Saving a scenario, exiting and re-loading that scenario appears to 'clean the slate' in terms of recovering any memory that might have been leaked out during the course of a flight (no surprise here)

[SteveW 1,792]

737 and OP=0 used 15.7Mb less in your test looking around inside and outside Rob. A fixed view across the VC of the 737 and this time OP=1 used 100.3Mb less. Starting all at 13:00 and no weather etc.

[Guest]

 

 

1) Transition fro day to dusk seemed to consumed a small amount of VAS (but AI traffic could have been the variable)

 

This can vary based on location and scenery installed and graphics settings.  To test the day to dusk transition you need to increase the frequency of VAS polling in order to capture the memory spike.  What looks to be happening during this transition is the release of texture resource for day happen after the loading of dusk resources (perhaps this is just part of the blending process) so there is a very short period of time (<1 sec) where VAS spikes and then falls back down to about the same level.  This test was actually done in V3.3 and I reported to LM.

 

 

Video maybe hard to see VAS number if not viewed at 1440p or higher ... but if you go to the 5:00min mark and watch transition from Day to Dawn in this case, at 5:27 min there is a VAS spike to 3.8GB before it settles back down 3.3GB.  Same issue when going from Day to Dusk ... see 6:30 min watch til 6:53 min you'll see a spike to 3.8GB before it settles back down to 3.3GB.  It's the VAS spike that can trigger the OOM, especially if I used a more complex aircraft/location in my video sample above.

 

Unfortunately it's the VAS spike that can trigger the OOM which would obviously prevent P3D from recovering the VAS since it has now crashed.

 

Keep in mind, my testing above was done with extreme graphics settings with many add-ons installed.

 

Cheers, Rob.

[SteveW 1,792]

Same result with and without deleting the Shaders folder, the relevant shaders are rebuilt as a consequence to the settings in cfg. Doesn't hurt to delete the entire folder, just takes longer to rebuild them. I suppose with incremental updates it might be possible that some .cfg changes don't fully bubble up to the shaders but seems no worries in this case.

[G-YMML1 582]

Folks,

 

Do you suggest to delete camera.cfg file and let P3D to rebuild it? I thought that camera.cfg has EZDOK entries included, hasn't it?

[odourboy 1,289]

Revised results based on Rob's recommended process; Optimize Parts = 0 saved me 62Mb with 737NGX at KEWR with DD NY city V2 scenery,

 

However, it COST me about 5 FPS, 22 versus 27 and the 22 FPS was rough! Clearly for my system with this sort of scenario, I will look elsewhere to recover my 62Mb. :smile:

[Navigator43 25]

Rob I put optimize parts back to 1 and the VAS issue hit again. So no doubt in my mind it seems to be something related to optimize parts

Also I did lose a few FPS in the long run with optimize parts 0 but nothing over the top

[Chaos81 110]

Ran the test twice (2 each for 0 and 1) following Rob's instructions in post 18 and both times Optimize Parts = 1 left me with a little bit more VAS remaining. That said, all 4 results were within 50MB of each other so it's tough to say it was anything other than random variance. This was with the 777 at KIAD. 

 

I'll try the NGX later tonight to see if I get the same results.