P3D "Out of Memory"

[OmniAtlas 93]

I've never been so frustrated with OOM -- even more so then FSX. 

 

I have LOD scaled down to the lowest. Autogen is at its second highest level.  All the rest at the top (same settings as in FSX). 

 

I have a 660 TI OC running with 8 GB ram, Windows 7, and a 2500k overclocked to 4.6 GHz. 

 

I'm also running OPUS and notice lots of clouds when it crashes -- could this be the source? 

 

Thank you.

[WR269 367]

why would you run the same settings as fsx? this is not the same sim, doesbt even have the same name, it doesnt inject textures the same way or in the same quantity. I have the same card as you and I have not had a single CTD or OOM. you need to start from scratch, tune the sliders until you get a good sim performance, not a slider performance, otherwise it will be horribly frustrating.

[OmniAtlas 93]

It runs okay graphically averaging 30-40 fps. When I have a graphically intense airport (e.g payware) that is when I start getting OOM.

 

I am also running an airbus cockpit suite (jeehell) on the same computer - would this limit my ram for p3d? I thought p3d only has 4 gb to work with so I am fine.

[WarpD 824]

Sliders all the way to the right are not the same settings as FSX.  Not by any stretch of one's imagination.  It's a great deal higher than the maximum FSX settings.

[Guest]

 

 

I have a 660 TI OC running with 8 GB ram, Windows 7, and a 2500k overclocked to 4.6 GHz.

 

Somethings to consider with OOMs and P3DV2 (assume you mean V2):

1.  Screen resolution (the more resolution the more the impact on VAS)

2.  Texture sizes (1024, 2048, 4096)

3.  Shadow/HDR settings

4.  Scenery setting (I can't run the sliders all the way to the right)

5.  64bit Win7 or 32bit Win7?

6.  GPU VRAM (I've used 3.8GB VRAM - the more GPU VRAM you have the better)

7.  Clouds will increase VAS usage (especially 110mi distance, I usually set to 80mi)

8.  3rd party Aircraft will have a HUGE impact on VAS usage

9.  3rd party AI traffic products have a huge impact on VAS

10.  3rd party airports will vary A LOT on their impact on VAS

11.  3rd party scenery products like FTX Global/Vector will impact VAS

12.  LM have acknowledge some memory leaks and will be fixing for 2.05 update due out this month (Jan)

 

P3DV2 is begging to be a 64bit application/executable, but that's not likely to happen any time soon (not confirmed by LM and not even officially listed in any future version) -- so just like FSX, we all have to play the OOM game and be careful about what 3rd party products we install, what settings we use, etc. etc.  Like I've suggested before, P3DV2 not being a 64bit application/executable is probably it's biggest weakness right now, just have to hope that 64bit becomes a priority for LM (it's a slim hope).

 

When PMDG release their "commercial" use license for their aircraft products for P3DV2 the OOM problem is only going to get much worse ... we'll all have to defeat many of the cool graphical features available in P3DV2 just to be able to run a PMDG aircraft ... IMHO defeats the purpose - why use P3DV2 with PMDG when one has to turn down the settings so much that is looks like FSX?

 

But it is what it is and adjustments will have to be made in P3DV2 just like they are being made in FSX ... if you want to be unshackled by the 32bit address space limit, you'll need to explore XPlane-10 64bit and see if that meets you goals/desires in flight simulation.

 

Rob

[Noel 4,487]

 

 

...why use P3DV2 with PMDG when one has to turn down the settings so much that is looks like FSX?

 

This has been my assumption since using V2--that this sim will be primarily for VFR or lower complexity planes for the common user.  I think the NGX might be OK as long as you restrict use to lesser terminals.   Combining a PMDG bird and a FSDT airport will likely not do well, but this could hinge a little on 'optimization' for V2, but who really knows what that can bring, optimization that is.  I also find the impact of certain sliders in V2, for my system which is very similar to yours, doesn't have that big of an impact such that lowering sliders for PMDG birds may not improve the picture much in the end.  If you haven't installed the CS Super MD80 Pro it's a fun one to use, dreary as the VC can be compared to the T7, to test airliners in more complex airports.  The MD80 is so easy to process for FSX and this translates well to V2.   It's complexity:performance ratio is very favorable.

 

What I'd really like to watch is for LM to use the code they have essentially as a template for building a new sim that follows a similar basic layout, however going native 64-bit and here's the real clincher, adding much more robust multithreading/multicore optimization.  Love to see my 5 of my 6 cores running at 90% which I think is what Srdan Word Not Allowed clamors for.  I understand there is a good reason this doesn't happen even for XP10 I assume because synchronizing tasks in a simulator is difficult to do, i.e. the demands of a flight sim don't line up well w/ multithreading/multicore use.

[Guest]

CS Super MD80 Pro

 

Hi Noel,  will have to check that aircraft out ... I was planning on moving the default FSX CRJ as I really enjoy that Aircraft and it's lite on VAS.

 

 

 

Love to see my 5 of my 6 cores running at 90% which I think is what Srdan Word Not Allowed clamors for.

 

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.  There is never going to be a point where thread timing is ever going to be complete in such a way that all cores are going to be used all the time ... think about all that must happen in a flight simulator, from instruments to ATC to flight dynamics to graphics to weather to ... flight simulation is NOT like a simple "render task" from say video software or 3D animation software ... it's far more complex and timing bound ... meaning you don't just render one chunk and them move on to the next chunk as the real world one emulates doesn't fall into such ordered processing -- there is always going to be "wait time".

[Noel 4,487]

 

 

a more realistic goal is between 33-50% across all cores

 

Well, we're in the Promised Land then because if I recall last time I checked that was the range I was seeing in all but Core0 as predicted w/ the AM of 62.

[jjjallen 37]

Did anyone ever wonder how much memory the OS (Windows 8.1) is allocating to the P3D (Procs[0]) process?

 

Procs[0].PrivateMemorySize 413548544 int

Procs[0].PrivateMemorySize64 413548544 long

Procs[0].VirtualMemorySize 891670528 int

Procs[0].VirtualMemorySize64 891670528 long

Procs[0].PeakWorkingSet 413511680 int

Procs[0].PeakWorkingSet64 413511680 long

Procs[0].PeakPagedMemorySize 421322752 int

Procs[0].PeakPagedMemorySize64 421322752 long

Procs[0].PeakVirtualMemorySize 905191424 int

Procs[0].PeakVirtualMemorySize64 905191424 long

 

Regards

jja

 

 

[Guest]

 

 

Well, we're in the Promised Land then because if I recall last time I checked that was the range I was seeing in all but Core0 as predicted w/ the AM of 62.

 

Consider this:

 

An i7 3960X processor can operate about 3 Billion instructions per second.  External tools used to monitor CPU utilization (process explorer, task manager, etc. etc.) typically pole the CPU about ever 500ms (1/2 second) to 1000ms (1 second) ... so those monitoring tools are obtaining a tiny tiny fractional snapshot of what the CPU is doing ... it's simply just not accurate (sorta like trying to play back digital audio that was sampled at 1 hz rather than 44.1 Khz - it will sound beyond horrible and unrecognizable).  A lot can happen between each pole interval and a lot of waiting can happen between each pole interval that you don't see in those external monitoring tools.

 

To obtain accurate CPU utilization with threading one really needs the source code and a special build/compile for the soul purpose of profiling.  Only then can you start to get a true representation of CPU utilization and the slow spots over time and various situations.  Then starts the task of reading and understanding that information which in itself is NOT trivial.

 

I'm pretty sure Word Not Allowed doesn't have access to LM's source code, nor the tools he would need to profile the code.

 

But my main point is that it's unlikely that anyone (on this planet) could optimize/design a complex product like a flight simulator in such a way as to never have the CPUs waiting (100% utilization) or even waiting only 10% of the time.  I'm sure there could be some additional thread optimization done but your not going to see a huge change in CPU utilization.

[OmniAtlas 93]

Running at 1080p, texture sizes 4096. No HDR. Shadows are set to medium. Running 64bit Windows 7. Clouds are set to 80 mi. I've turned off volumetric fog -- at least I can take off and reach 10,000 feet now before a crash

 

AI is set to 40% but there are no AC around -- perhaps I will tone that down.

 

I am running the iFDG airbus 320 with no virtual cockpit and running Jeehell cockpit suite (free!) externally.

 

Hopefully the patch will fix the memory leak issue. 

 

 

Somethings to consider with OOMs and P3DV2 (assume you mean V2):

1.  Screen resolution (the more resolution the more the impact on VAS)

2.  Texture sizes (1024, 2048, 4096)

3.  Shadow/HDR settings

4.  Scenery setting (I can't run the sliders all the way to the right)

5.  64bit Win7 or 32bit Win7?

6.  GPU VRAM (I've used 3.8GB VRAM - the more GPU VRAM you have the better)

7.  Clouds will increase VAS usage (especially 110mi distance, I usually set to 80mi)

8.  3rd party Aircraft will have a HUGE impact on VAS usage

9.  3rd party AI traffic products have a huge impact on VAS

10.  3rd party airports will vary A LOT on their impact on VAS

11.  3rd party scenery products like FTX Global/Vector will impact VAS

12.  LM have acknowledge some memory leaks and will be fixing for 2.05 update due out this month (Jan)

 

[smpetty 6]

I keep my sliders one step short of full right and had terrible problems with OOM errors in P3D v2 until I dropped my textures to less than 4096. It was best with textures at 1024 but still pretty reliable at 2048.

 

Scott

[Guest]

 

 

It was best with textures at 1024 but still pretty reliable at 2048

 

Hey Scott, I noticed there wasn't much of a difference between 1024 and 2048 (even with REX 4 at 2048 and lots of clouds) also.  Almost completed a full flight last night from Los Angeles to Lake Tahoe going from day to dusk to night and just on final approach I heard the chime but it was too late ... I wasn't fast enough on the Save Flight and it OOM's.  What's odd is that FSUIPC seems to give less warning time (chimes) with P3DV2 and sometimes NO warning chime at all ... I think FSXAssist is promoting an AutoSave feature which would come in handy for P3DV2.

 

Anyway, supposed to get a patch from LM this month, so lets keep our fingers crossed.

 

Rob

[Noel 4,487]

Hey Scott, I noticed there wasn't much of a difference between 1024 and 2048 (even with REX 4 at 2048 and lots of clouds) also.  Almost completed a full flight last night from Los Angeles to Lake Tahoe going from day to dusk to night and just on final approach I heard the chime but it was too late ... I wasn't fast enough on the Save Flight and it OOM's.  What's odd is that FSUIPC seems to give less warning time (chimes) with P3DV2 and sometimes NO warning chime at all ... I think FSXAssist is promoting an AutoSave feature which would come in handy for P3DV2.

 

Anyway, supposed to get a patch from LM this month, so lets keep our fingers crossed.

 

Rob

 

Rob, what the heck is happening here.  I do not get OOMs and I use 2048 and even 4096 textures, flying between for example KSAN & KPDX w/ FTXG installed.   Did you uninstall the Hawaiian airports yet and see?

[Guest]

I wasn't fast enough on the Save Flight and it OOM's.  What's odd is that FSUIPC seems to give less warning time (chimes) with P3DV2 and sometimes NO warning chime at all ... I think FSXAssist is promoting an AutoSave feature which would come in handy for P3DV2.

 

Why not use FSUIPC's Autosave…? And btw FSUIPC often gives no warning because the OOM's aren't your regular OOM's: P3D often suddenly floods the VAS, resulting in an OOM. And quite often even long before VAS has reached 4 GB. The memory system of P3D is flawed. With FSX I never ever had to worry about OOM's but with P3D it sometimes seems I am playing a 'Watch-out-for-the-VAS-game'...