I never encountered an out of memory shutdown in all my years of FSX simming. I recently went from a Dell 2410 to a Dell 3415 Ultrawide and now am having significant OOM shutdowns on saved identical flights that I did fine with before..

 

Could converting to the Ultrawide be causing my OOM errors?

 

Only other possibility is using ASCA 2016 full dynamic mode which is new for me.

 

Thanks

 

Grg

It could well may be. I have the same monitor and at the beginning started having OOM errors. I had to turn down the AI traffic slider and it has been good so far. I'm running with a GTX 970 and I'm tempted to get a GTX 1080.

Thanks helpful to know someone else may be having this issue. I am running 1070, which I upgraded to from old 580 prior to getting the new monitor. I will see if turning down the traffic settings helps.

 

Greg

Not helpful but can I just add that I have the Dell 3415 monitor and a GTX 1070 and use AS2016 with ASCA. I don't have any OOMs with either P3D v3.3.5 or FSX (DX10). I also have Orbx FTX Global and LC and use PMDG 737, 777, UTII. The graphic sliders for the sims are mid to high with unlimited frame rates.

I have been using the Dell 3415 for about a year without any issues.

Could converting to the Ultrawide be causing my OOM errors?

 

I don't know how literally you intend your question. It seems plausible that more than doubling the number of pixels you're asking FSX to calculate and display could affect memory usage. The shape or aspect ratio of your monitor as the cause seems less plausible.

Not helpful but can I just add that I have the Dell 3415 monitor and a GTX 1070 and use AS2016 with ASCA. I don't have any OOMs with either P3D v3.3.5 or FSX (DX10). I also have Orbx FTX Global and LC and use PMDG 737, 777, UTII. The graphic sliders for the sims are mid to high with unlimited frame rates.

I have been using the Dell 3415 for about a year without any issues.

Same monitor, max settings on FSX/P3D/XP 11 and no oom's...

If you're using FSX with DX9, the increased screen resolution will result in an increase in VAS used, as DX9 maintains a video buffer in system RAM.  The quickest cure for that is to move to DX10 (or P3Dv3).  There are some growing pains associated with that, but Steve's DX10 Fixer takes care of most of them.

 

HD clouds can kick your butt, too.  I use 512x512 res clouds in ASCA and it looks fine without clobbering my VAS usage.

 

Regards

I don't know how literally you intend your question. It seems plausible that more than doubling the number of pixels you're asking FSX to calculate and display could affect memory usage. The shape or aspect ratio of your monitor as the cause seems less plausible.

im a little more than stupid when it comes to VAS and how p3d manages itself in term of cpu and gpu usage. please forgive me.

 

I always thought rendering pixels would be all done by the GPU and it would be VRAM that would affected. Not the 32bit limitation. Please educate me on this.

The OP appears to have been asking about FSX, which is a much different animal than P3D in the graphics dept, and the answer you quoted was specific to FSX.

 

P3D uses DX11, which allows the main program to push objects to the GPU with instructions on where to place and orient them, and the GPU does that heavy lifting, as well as doing the masking when one object is hidden behind another, shadows, lighting etc.  In FSX with DX9, the CPU has to compose the entire frame in a local buffer (using FSX's VAS) and push it out to the GPU's frame buffer.  More pixels (bigger frames) means more VAS.  There is still some frame composition work and some memory loading associated with a larger frame in DX11, though not as much...and each object to be added to the larger frame still has to reside in VAS (both the wire frame and textures associated with it), although there are some efficiencies involved in pushing an object (e.g. a particular type of tree) and instructing the GPU to place it in multiple locations/orientations.  Since DX11 is doing the frame composition in Windows' system VAS, DX11 does not entail keeping a local copy of the frame buffer in the application's VAS.

 

Regards