VAS Usage in P3DV2

[vonmar 122]

This is what I'm using per Pete:

 

FSUIPCVas1.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.

[mgh 89]

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..

 

 

 

 

 

 

[Guest]

 

 

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

[Noel 4,487]

 

 

 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.

[Guest]

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?

[vonmar 122]

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

[Guest]

 

 

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.

[Guest]

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.

 

 

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).

[mgh 89]

 

 

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.

[Guest]

 

 

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.

[Guest]

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

 

Could you summarize it for me? I've not been able to get to the forum for quite some time now due to bad connections (the rest of the internet is fine over here...!).

 

Never mind, managed to reach the forum just now!

[vonmar 122]

Jeroen,

 

Just for information.

I am at KDTW and the connections to AVSIM have been very slow for weeks now .. many times at 4am (-4 GMT) I cannot connect at all.

Other internet sites are always ok.

[Guest]

 

 

I am at KDTW and the connections to AVSIM have been very slow for weeks now

 

About all we can do to improve AVSIM is click on the button just above this thread entry ... "Donate" ... and hope there is enough to move AVSIM to a more powerful server(s) - 120,000 members donate $10 each $1.2 Million - that should make it happen