I still don't think memory fragmentation under VAS implementation is much to worry about in P3DV2 ... there are other issues that I think is the cause of sudden VAS consumption (well beyond any wasted page segment allocations).

 

The "add-ons" seem to be the primary cause of my VAS consumption, without them I wouldn't OOM even at 4096 textures -- but there again, how many textures really are 4096 in the default P3DV2 release?  As I understand it, that's just allowing the use of 4096 textures and doesn't necessarily mean there will be 4096 textures in any given situation.  With that said, I believe P3DV2 does provide 4096 cloud textures?  Feel free to correct me as I'm not sure.

 

From what I can tell, there are some textures that will consume VAS and some that will not and live cached in the GPUs VRAM.  For example, at some regions I will see my GPU VRAM at 3.8GB while my VAS is < 3GB ... while in other regions I'll see GPU VRAM at 2.1GB while VAS is at 3.8GB.  So it's very difficult to pin-point what exactly is causing the high VAS usage.  Sim720 Inverness is another airport/area that seems to cause high VAS usage (3.7-3.8GB), yet a very similar Sim720 airport (Stornoway) will be 3.4GB VAS or less.  So clearly something is "up", exactly what I have no idea -- I don't even want to guess but welcome thoughts on it.

 

Rob

...how many textures really are 4096 in the default P3DV2 release?  As I understand it, that's just allowing the use of 4096 textures and doesn't necessarily mean there will be 4096 textures in any given situation.  With that said, I believe P3DV2 does provide 4096 cloud textures?  Feel free to correct me as I'm not sure.

Rob, I have found only one texture in P3Dv2 that is larger than 1024^2...

 

...GlobalEvnTest.dds file which is 3072x512 6.1MB.

 

This texture is almost never used, but is available if needed for "chrome" to use.  :Whistle:

Rob, I have found only one texture in P3Dv2 that is larger than 1024^2...

 

...GlobalEvnTest.dds file which is 3072x512 6.1MB.

 

This texture is almost never used, but is available if needed for "chrome" to use.  :Whistle:

Interesting.  Is there a downside to setting the global texture resolution at 4096, even when there are few to no higher resolution textures?  If so, what exactly is the downside?  Does it for example, 'reserve' the 4096 as an address space in VRAM, even though each address space will only be utilized by a 1024 block of texture data?  If so, would this make a VRAM sensor such as found in GPU-Z display much higher memory used value, up to 4x more 'use' than was actually 'needed' as it were?

Noel good question :rolleyes: i have not seen many OOM,s in fsx the last 2 years actully only 1 and that was with the 777 from pmdg,i have just reinstalled the whole system and fsx and now with the dx10 fixer,and fsx in running great,so we see if i get any problems,i dont hope so.

Interesting.  Is there a downside to setting the global texture resolution at 4096, even when there are few to no higher resolution textures?

I honestly don't know the answer to that, but I suspect not, unless one has 4096 textures installed. I assume that the GTR setting is there mostly for future scalability.

 

What I do know is that if one has GTR set for 1024, and does have 4096 textures being used, P3Dv2 will only display the LOD that corresponds to the 1024 sized MIPs, but still consume the full 4096 VAS allocation.

 

 

What I do know is that if one has GTR set for 1024, and does have 4096 textures being used, P3Dv2 will only display the LOD that corresponds to the 1024 sized MIPs, but still consume the full 4096 VAS allocation.

 

Well, that sucks. I always use 1024 so if I get a plane that has 4096 textures, I maybe should resize the main parts of that plane?

 

 

What I do know is that if one has GTR set for 1024, and does have 4096 textures being used, P3Dv2 will only display the LOD that corresponds to the 1024 sized MIPs, but still consume the full 4096 VAS allocation.

 

VAS eh, not VRAM?  I guess it starts in VAS then is rendered in the GPU and sent to VRAM then to the screen?  Well, weirdly, I don't have OOMs and most of my time in V2 so far was w/ GTR at 4096.

 

He's living a dream, 90% across all cores is never going to happen with a complex flight simulator ... a more realistic goal is between 33-50% across all cores.

 

My bad, the '90%' comment on my part was not provided by Word Not Allowed but was just my estimation of what Word Not Allowed might have meant when he actively promotes better/proper multithreading of the simulator as a worthwhile goal. Rob says 33-50% across all [non-masked] cores is realistic but that seems to be very much the range Asus Suite per/core utilization shows FWIW.

VAS eh, not VRAM?  I guess it starts in VAS then is rendered in the GPU and sent to VRAM then to the screen?  Well, weirdly, I don't have OOMs and most of my time in V2 so far was w/ GTR at 4096.

Both, actually. Every file your computer uses data bits. Those data bits are stored in system RAM, while the ADDRESSES for those data bits is kept track of via the VAS. (Hence the name Virtual Address Space) :Whistle:

 

It's not an either/or binary choice; it is a both/and reality!

 

In actual operations, stuff is constantly flying back and forth from RAM to VRAM, and the VAS is likewise constantly being updated...

Has there been an update recently to the sim? I haven't flown for a while. I'm having issues keeping the sim running for more than a few minutes at a time w/o getting an OOM Error. It was fine just a few weeks ago. Even lowered my stuff to see if it'd fix it.

 

LOD Radius 4.5 (used to run at 6.5 

Sliders set to dense for the most part (used to run at very dense when i last flew without crashes) 

Texture resolution 1024 (used to run 4k) 

Traffic set to 0 

FPS limiter set to 30 (used to have it set at unlimited w/o crashes) 

Shadows Medium

Water Medium

 

Using FTX Global, FS Global Ultimate Mesh, REX3, OpusFSX 

 

Flying the default planes for now. 

 

i7 3770k @ 4.2Ghz

7970 Toxic 6GB

Asus Sabertooth 

16GB Kingston Dominator 1600Mhz

Win 7 64b.

Eyefinity 5760x1080

No, there has been no update yet. L-M are still working on it.

Has there been an update recently to the sim? I haven't flown for a while. I'm having issues keeping the sim running for more than a few minutes at a time w/o getting an OOM Error. 

 Ouch, must be one of the add ons you have or an update to Win 7?  I'm apparently rather fortunate in that I've never seen an OOM despite having 2 aircraft, mesh & FTXG & REX3 installed.  I keep expecting them but nothin' so far.

 

 

Eyefinity 5760x1080

That sure is a lot of pixels you are running through the pipeline.

Looking at windows task manager -- at my default airport (YBBN), with OPUS opened and Jeehell airbus (external cockpit suite) opened I have used about 4.69 GB of ram. 

 

I quickly crash after flying for a few minutes. 

 

Would upgrading to 16 GB of ram be helpful at this stage because I am already using a memory intensive external program (Jeehell)? 

 

 

Looking at windows task manager

 

You'll want to use Process Explorer here (free): http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx to help determine your VAS usage relative to Prepar3d.exe.

 

If you're running a 64bit OS, then you'll want 8GB min ... more is obviously always better especially if you run external programs beyond the normal OS services and background tasks.

You'll want to use Process Explorer here (free): http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx to help determine your VAS usage relative to Prepar3d.exe.

 

If you're running a 64bit OS, then you'll want 8GB min ... more is obviously always better especially if you run external programs beyond the normal OS services and background tasks.

 

Thanks, monitered process explorer while running P3D -- looks like it crashed around the 7 GB mark. :(