Sign in to follow this  
Rob Ainscough

Excessive VAS usage in P3D V3.4 triggered by OPTIMIZE_PARTS

Recommended Posts

FYI, LM have a ticket open for possible VAS issues in P3D v3.4 and I've been working with them on it.

 

I believe I have found one possible source of the excessive VAS usage, please try changing the following entry in your Prepar3D.cfg:

 

[sIM]
OPTIMIZE_PARTS=0
 
The default value is 1, set the value to 0.
 
Important that you delete your Shaders folder (i.e. C:\Users\Rob\AppData\Local\Lockheed Martin\Prepar3D v3\Shaders) after making this changes.  
 
So far I've seen about 250 MB VAS reduction when testing with Milviz 737-200 and PMDG 737-600.  
 
This is NOT going to cure OOMs in P3D, graphics settings and many add-ons can still OOM P3D, but it might explain the VAS difference between V3.3 and V3.4.  In V3.3 the OPTIMIZE_PARTS=1 was mostly beneficial in performance and VAS, but in V3.4 that seems to have changed.  Hopefully LM can isolate and report back.
 
If anyone cares to try this change, please report back your findings and which aircraft was used.
 
Cheers, Rob
  • Upvote 1

Share this post


Link to post
Help AVSIM continue to serve you!
Please donate today!

AFAIK OPTIMIZE_PARTS=1 should optimize usage of all cpu cores? No performance difference with =0?

Share this post


Link to post

Will try rob might help my poor 747 if i could gain back 250 i would be very happy

Share this post


Link to post

OPTIMIZE_PARTS is related to aircraft models ... nothing to do with CPU cores/threading.

 

Cheers, Rob.

Share this post


Link to post

I'll give it a try.  I have a noticeable increase in OOMs  with 3.4.  From zero in 3.3 to roughly 3 out of 5 flights in 3.4.

Share this post


Link to post

Yes, 3.4 is definitely got a ~200/300 Mb of VAS usage

Share this post


Link to post

Yes, LM is aware.  

 

So anyone reporting back from setting OPTIMIZE_PARTS=0 in terms of VAS usage?

 

Cheers, Rob.

Share this post


Link to post

Good Morning Rob,

 

Thanks for the heads up and postimg this here.

I tested it a moment ago and have to say that i cannot see any difference in VAS use....

 

Will try more scenarios today and report back.

 

Anyway thanks again, Carsten

Share this post


Link to post

 

 


So anyone reporting back from setting OPTIMIZE_PARTS=0 in terms of VAS usage?

 

Hi Rob,

 

I did a quick test.

 

OPTIMIZE_PARTS=1

Aerosoft EDDF v2, PMDG 777, No weather -> 1.21 Gb free VAS after loading, 1.29 Gb free VAS after approx. 1 minute just sitting on the runway

 

OPTIMIZE_PARTS=0

Aerosoft EDDF v2, PMDG 777, No weather -> 1.25 Gb free VAS after loading, 1.31 Gb free VAS after approx. 1 minute just sitting on the runway

 

So no significant change in VAS. With 1.3 Gb free VAS in the above scenerio, free VAS is approx 100 Mb lower than in v3.3 on my system.

Share this post


Link to post

OPTIMIZE_PARTS=1 saved around 100-200Mb PMDG737. Shaders rebuilt after changing setting without deleting folder.

Share this post


Link to post

OP...parts=1 FT YSSY Orbx AU   AS2016 PMDG737 NGX Free VAS=1302 dropped to 1242 after 1 min

 

OP....parts=0  Same as above =VAS Free 1241

 

Seems no difference.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

 

 


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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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)

Share this post


Link to post

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.

Share this post


Link to post

 

 


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.

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this