Thought I'd share my observations on VAS usage in P3DV2 with Various add-on products.

 

How I tested:

1.  See P3DV2 settings here: http://www.robainscough.com/Prepar3D_Settings_2.html

2.  Start P3DV2 at Minnesota - St.Paul KMSP and use the Carenado A36 aircraft - weather is clear (no clouds at all)

3.  Bring up menu and select Time and Season and set time to 11:46 AM and Season to Winter with date at Jan 4th 2014 (note, this process consumes 100MB on my system, not sure why when the only real adjustment was 10 minutes on time)

4.  Make sure I'm not in Pause mode and do a slow (want to make sure all textures are loaded into view) full 360 view rotation in VC -- repeat it twice (very important)

5.  Wait about 30 seconds and note VAS free (I'm using FSUPIC to show free VAS and also confirmed it's relative accuracy with Process Explorer)

 

Here are some of my results from various 3rd party products:

 

AccuFeel 2.0 @ 120 MB increase

Bglmanx (Virtuali FSDT/FB etc.) @ 87 MB increase

Orbx Vector @ 221 MB increase

Pilot's FS Global 2010 FTX Edition @ 45 MB increase

FTX Global 1.2 @ 20 MB decrease

FSUIPC 4.9.27a @ 7 MB increase

 

Orbx Vector was a bit of a surprise ... but perhaps that's because with more roads comes more animated traffic.  Removing FTX Global 1.2 seeing worse VAS usage (it went up a little) was a little surprising also, but this was day time (with no lights) so maybe not unexpected.  

 

What has me really puzzled is the process of just opening up the Time & Season menu and setting the time back only 10 minutes from 11:56 am to 11:46 am and returning to main VC view consumed 100 MB??  Very puzzled with that one ... perhaps a bug?

 

Just reporting my observations and NOT trying to set any precedence.

 

Cheers, Rob.

(I'm using FSUPIC to show free VAS

 

How do you do that Rob? And where does it display free VAS?

My experience is that VAS usage is good in P3D v2, but there is most definetly a bug somewhere. VAS seems to build up over time, even if you never leave the ground just by doing changes to time, season and display settings (among other things). For instance. If you slowly add display features then try to turn them back down, VAS doesn't come back down. I did several graphics tests without 0% traffic to make sure it wasn't building up in the background. (http://simmerhead.wordpress.com/2013/12/01/the-preapar3d-v2-diary-1-vas-bug/)

 

It is no surprise that FTX Global Vector has a big VAS footprint. Back in the early FSX days I remeber how UTX brought FSX from a crawl to a creep . Detailed vector polygons is almost like adding additional autogen to a scenery.

How do you do that Rob?

 

 

This is what I'm using per Pete:

 

That facility is also available in the free version of FSUIPC.

Another observation on VAS ... if I do a flight from A to B that consumes 600MB VAS ...then I "Reset" the flight it doesn't free up any VAS at all.  This tells me that LM have got some work to do on resource deallocation front.  Only way to get VAS back is to exit P3DV2.

I also noiticed the build up of VAS when you just chante settings. I tested this shortly after I got my first OOM: I can't exactly remember the exact numbers but when the flight started VAS was around 1.75 and by only changing settings (graphics, etc.) and by changing time and things like that I could get VAS up to something like 2.30. Again, something like that. And that was without flying. I might repeat the test this afternoon to see what changes make a real difference. Anyway, after this test I figured out it is best to prepare the flight into detail as much as possible, so make good use of the startup screen and try to avoid having to use the menu at all times.

 

BTW I don't really understand why it isn't possible to remove things from VAS 'on the fly'. Do other programs do that or is it a limitation of the system? Why does everything have to be remembered as you fly along?

 

 

Why does everything have to be remembered as you fly along?

 

I'm going to guess for performance reason - deallocation takes processing cycles ... sorta like when one deletes a record from a database, it just marks a delete bit leaving the record fully intact using space -- the actual space recovery is done later with a separate manual or automated process.

 

But not deallocating resources AFTER a "Reset Flight" does seem a little strange ... gotta believe this is a bug.  The flight is being reset so it's a perfect time to do the deallocation/recovery because one is not in a state where performance is needed.

 

In my testing above, noticed I said make two full 360 view rotations (slowly) to ensure everything is being loaded ... pending the location one can start out at 2.2GB and by the time one has done 2 full 360 rotations in VC, VAS is up to 3.1GB.  There is a significant difference in VAS usage (must less) if two full 360 rotations are NOT done.

 

 

But not deallocating resources AFTER a "Reset Flight" does seem a little strange ... gotta believe this is a bug.  The flight is being reset so it's a perfect time to do the deallocation/recovery because one is not in a state where performance is needed.

Good research on this Rob.  Have you reported your findings to LM?

 

 

Have you reported your findings to LM?

 

Posted a thread over in LM's forum.

 

Another observation on VAS ... if I do a flight from A to B that consumes 600MB VAS ...then I "Reset" the flight it doesn't free up any VAS at all.  This tells me that LM have got some work to do on resource deallocation front.  Only way to get VAS back is to exit P3DV2.

 

 

Good to see others have confirmed my findings. With limited VAS extra care needs to be taken! Thanks for posting over at the P3D forum Rob!

Not necessarily.

 

Windows DirectX 3D  can create a shader rather than dealing directly with a with a texture (.dds).  The consequence is that he shader can re-used. This means that there may be is no need to release the shader.  It may simply be re-used without being reset.

Good report Rob! My VAS builds up and builds up til I dump it be exiting P3Dv2. Got to be a bug somewhere.

It may simply be re-used without being reset.

 

I don't understand why LM would NOT want to release all the shader code on a flight reset?   What would the benefit be in not doing so?  I would think the odds the same user needing the exact same shader code applied to a pixel, vertex, geometry is pretty unlikely ... but either way, the shader code (Pixel, Vertex, Geometry) should be living in VRAM not VAS ... the GPU does the work, not the CPU.  

Posted a thread over in LM's forum.

Thanks for doing that sir.  Your knowledge and insight is valuable for this community.