Archived

This topic is now archived and is closed to further replies.

Guest

VAS Usage in P3DV2

Recommended Posts

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.

Share this post


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

(I'm using FSUPIC to show free VAS

 

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

Share this post


Link to post

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.

Share this post


Link to post

How do you do that Rob?

 

 

This is what I'm using per Pete:

 

FSUIPCVas1.jpg

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post

 

 


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.

Share this post


Link to post

 

 


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?

Share this post


Link to post

 

 


Have you reported your findings to LM?

 

Posted a thread over in LM's forum.

Share this post


Link to post

 

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!

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.  

Share this post


Link to post

Posted a thread over in LM's forum.

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

Share this post


Link to post

This is what I'm using per Pete:

 

attachicon.gifFSUIPCVas1.jpg

Thanks for sharing your settings ... I have Nvidia so I will better be able to check my system.

 

I noticed the FSUIPC VAS value will overprint the Frames Per Second and other data on the FS screen. Hard to read it.

Is there a way to display this data a few lines down on the display?

 

What is your memory usage with just your default flight loaded? Say, a typical value most users would see before adding other software.

Share this post


Link to post

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.

 

 

Why release it if it can be reused? The point is that the code isn't the same and is accessed via a pointer. Therefore, there need be no point in release if the only purpose is then to re-creating it.

 

A very simple example that switches views

if ((MyTime < 10000) || (MyTime > 11000))

{

D3DX11CreateShaderResourceViewFromFile(

MyD3DDevice,

L"Crate.dds",

NULL,

NULL,

&MyShaderResourceView,

NULL

);

}

else

{

D3DX11CreateShaderResourceViewFromFile(

MyD3DDevice,

L"dot.dds",

NULL,

NULL,

&MyShaderResourceView,

NULL

);

}

 

 

 

// Sets the buffers used by the pixel shader pipeline stage

MyDeviceContext->PSSetShaderResources(

0,

1,

&MyShaderResourceView

};

 

// Swap the back buffer with the front buffer

HRESULT MyResult= MySwapChain->Present(

1,

0

);

 

 

Note that the shader resource view can be reused with a  different view without the need to recreate it..

 

 

 

 

 

 

Share this post


Link to post

 

 


Why release it if it can be reused?

 

Because it's not the same view (texture resources) and there is no "big" penalty in reloading them as needed (which is what happens during the 1st flight).  Also, if they are being "reused" why does the VAS usage continue to increase until OOM on the 2nd flight -- which would indicate they are NOT being re-used at all.  If I do a flight from A to B and use 600MB, reset flight (this is a P3D RESET Flight, not just a position move) back to A, then do the same flight from A to B again VAS will increase another 600MB (1.2GB total or OOM, whichever comes first).

 

View is the resource (pointer to the structure "crate.dds"), shader is just the code operating on the resource -- why keep the resource loaded?  The crate.dds may only be needed 1000 miles away at the location "B" when  landing ... reset flight brings me back at airport A where no such "crate.dds" is part of the view/scene.   

 

But, the .dds should be living in VRAM for fast GPU operations on it so also don't understand why the VAS impact?   Pointers aren't huge consumers of VAS (even a lot of them).  But with that aside, the resource needs to be released as well as the shader resource view ... all of them ... there isn't much D3D documentation on this and I recall reading an thread about this here: http://gamedev.stackexchange.com/questions/54707/do-textures-that-are-inside-a-shader-resource-need-to-be-explicitly-released-too which made it clear to me that releasing just a texture alone doesn't remove it from memory if other shader resource views are referencing it.

 

But no matter how ya slice it, something is not happening during a Flight RESET that should be happening ... there is no need to hang onto a crate.dds resource that you may never need again ... if that were the case think of all the possible resources that get loaded during a flight that may never be needed again, but continue to live on even with a flight reset (massively inefficient use of resources and I have a hard time thinking this is by design).

 

I believe ESP is quad tree -- Jason Dent's implementation?   According to this article: http://www.microsoft.com/products/games/fsinsider/developers/pages/globalterrain.aspx (great read BTW).  But even with the complexity of design (the more I discover the more impressed I am, what an amazing product).  But I still can't understand why a RESET Flight doesn't release all those resources?  I gotta feel this really is a bug and not "by design".

 

my 2 cents,  Rob

Share this post


Link to post

 

 


 Only way to get VAS back is to exit P3DV2

 

Maybe this is why I never see OOMs--I always exit before starting any new flights.  I brought this behavior w/ me from FSX use where I also never saw OOMs.  And after long flights I will even reboot which now takes so little time it's no big deal to do.  Does sound like they need to fix this behavior though for sure.

Share this post


Link to post

I was trying out Oslo V2.0 airport (Aerosoft) today with my Twin Otter and got the OOM message with 700MB VAS free and only 2.6GB VRAM used.  This is the first time I've had an OOM message that wasn't a real OOM.

 

I recall someone else reporting this issue (OOM that really isn't) before ... but can't remember, with the P3D site down I can't go there to search.  Anyone else recall this issue?  Was there a work around?

Share this post


Link to post

Maybe this is why I never see OOMs--I always exit before starting any new flights.  I brought this behavior w/ me from FSX use where I also never saw OOMs.  And after long flights I will even reboot which now takes so little time it's no big deal to do.  Does sound like they need to fix this behavior though for sure.

Yes.

+1

Share this post


Link to post

 

 


I recall someone else reporting this issue (OOM that really isn't) before ... but can't remember, with the P3D site down I can't go there to search.  Anyone else recall this issue?  Was there a work around?

 

I am sure there were others also but my OOMs always occurred long before VAS reached 4 BG. I also had OOM's with VAS 2.5. It's my idea that something suddenly spikes VAS and it happens so quickly that the monitoring software can't even register the sudden change. The only work around I found was to limit to amount of add ons… Right now I only use FTXG and the A2A C172 and that's ALL. Hopefully LM finds a fix for this because it's not like it should be.

Share this post


Link to post

It's my idea that something suddenly spikes VAS and it happens so quickly that the monitoring software can't even register the sudden change.

 

 

Monitoring VAS isn't like monitoring CPU usage ... either the allocation happens or it doesn't and it'll show up in Process Monitor regardless of timing or FSUPIC memory monitor.

 

The good news is that the problem is easy to replicate and is consistently in the same exact location ... Oslo 2.0, taxiway N, heading towards runway 01L (see pic).  I'll pass this by Aerosoft support and see if they have any insight.

 

Oslo2OOM.jpg

 

If I taxi the opposite way towards 19R and takeoff from 19R, I don't get a "false" OOM.  However if fly back towards that same spot at 2000 ft, I will get the false OOM.

 

If I disable Oslo 2.0, I have no problems at that same (spot) or anywhere around that airport ... so this false OOM is specific to Oslo 2.0 and that specific location.  If I were to hazard a guess, there is some malformed object/texture/shader that causes P3DV2 to try to allocate more VAS than is available and it fails to allocate (showing the OOM message) even when there is plenty of VAS available.

 

What I've started doing now, per Noel's and other's suggestions -- is setup my flight (time/season/location/weather/etc.) and then save the flight at my starting point, and then exit P3DV2.  I've associated the .fxml files to Prepar3D and then just double click on .fxml flight file which will load P3DV3 at my starting point.  Also implemented the FSUIPC Autosave feature (another great suggestion).

Share this post


Link to post

 

 


I recall reading an thread about this here: http://gamedev.stack...ly-released-too which made it clear to me that releasing just a texture alone doesn't remove it from memory if other shader resource views are referencing it.

 

But that means surely that a ID3D11ShaderResourceView* can resuse  memory without its being released?

 

I am not saying that all your problems are caused by this.

Share this post


Link to post

 

 


But that means surely that a ID3D11ShaderResourceView* can resuse  memory without its being released?

 

Of course, the contention is that a Flight RESET should not re-use.

 

The VAS topic I started over at LM did get very interesting (even did a quick validation test myself) ... sorta disappointing actually because the implications are VERY obvious and I know 64bit is not a "near" future :(

 

Yeah, not sure what the Oslo 2.0 problem is ... if disable Oslo I don't have a problem ... shame because it's a VERY well done airport.

Share this post


Link to post