Converting to 64bit will not fix the problems that are causing OOMs.  Of course, everyone believes that unlimited memory is the "holy grail".

 

You're using addons written for FSX that are anything but optimized for use ( by absolutely any stretch of one's imagination) and then complain when they cause problems.

 

The math doesn't support the texture resolutions everyone's trying to run.  Do the math... 4k * 4k * 4 is how much memory is needed for ONE 4096 texture.  ONE.  So exactly how many 4k textures do you think you can load up before things start backfilling into your system memory?  At which point your performance drops... and if you keep shoving more and more 4k textures into memory... you run out of memory!!

 

It's basic math people... basic!

 

* You can get 16 4096x4096 textures into 1gig of memory.

No...it implies that all of the VRAM can't be used by FSX. It's not just a semantic difference.

 

 

 

Keep in mind that VRAM (a lot of it) is also used internally by the GPU for the post-processing (AA, AF) being done by thousands of parallel graphics processors. So even though the video frame buffer built by FSX may only use 0.5-1GB of VRAM, the GPU itself is also using a sizeable block of VRAM as working RAM to do its magic once it has grabbed the frame buffer and is ready for post-processing.

True, but that VRAM doesn't count against VAS which is the theme of this thread.

Converting to 64bit will not fix the problems that are causing OOMs.  Of course, everyone believes that unlimited memory is the "holy grail".

 

You're using addons written for FSX that are anything bug optimized for use ( by absolutely any stretch of one's imagination) and then complain when they cause problems.

 

The math doesn't support the texture resolutions everyone's trying to run.  Do the math... 4k * 4k * 4 is how much memory is needed for ONE 4096 texture.  ONE.  So exactly how many 4k textures do you think you can load up before things start backfilling into your system memory?  At which point your performance drops... and if you keep shoving more and more 4k textures into memory... you run out of memory!!

 

It's basic math people... basic!

 

* You can get 16 4096x4096 textures into 1gig of memory.

 

Halleluyah!

 

Exactly right Ed.  I suggested the same thing - that OOMs were not bugs or errors, but a boundary being reached due to the exact maths that you refer to, but it didn't go down well.

 

People get obsessed with HD in the sim but I'm very lucky in that I just don't think the likes of 4096 textures improve the flight and motion aspect of the sim at all.  (I'm lucky in that I never get OOMs because I prefer 1024 in most contexts).

 

The movement that our eyes perceive is not "HD".    Obviously a sensible resolution is a benefit over some low rez mess, but the obsession with super high resolution textures like 4096 (a la McPhat and some Carenado) is just one big red herring IMHO.

One of the worst purchases I've ever made was the Orbx Lancair.. That things texture management is one of the worst in the Flight Sim world. Its just 4096x4096 everywhere for no reason. That thing would OOM FSX on default scenery unless you backed down the graphics. No other plane OOM'ed me quite like that one.

 

Sent from my Nexus 10

Same goes for the PMDG NGX and T7, and FSDT/Flightbeam scenery.

 

Further, even if you conservatively run a TML of 1024, unless you've resized the textures themselves, you will still suffer the same VAS penalty.

 

 

Further, even if you conservatively run a TML of 1024, unless you've resized the textures themselves, you will still suffer the same VAS penalty.

 

Correct...because TML is one of several parameters that is used to limit the rate of transfer, not the amount of data to be transferred--the actual sizes and number of the textures to be transferred.

 

 

 

True, but that VRAM doesn't count against VAS which is the theme of this thread.

 

That's understood...my point is that FSX can drive VRAM usage far above what's actually used directly by FSX (and what's used directly is the only part that impacts VAS usage).  So it appears we're in violent agreement on that... 

 

Regards

So it appears we're in violent agreement on that...

We are, but it's a point worth making because it's often claimed otherwise.

Correct...because TML is one of several parameters that is used to limit the rate of transfer, not the amount of data to be transferred--the actual sizes and number of the textures to be transferred.

 

 

Before I sign off for a bit, just wanted to clarify, I am referring to TEXTURE_MAX_LOAD, the global texture resolution, not TextureMaxLoad.

True, but that VRAM doesn't count against VAS which is the theme of this thread.

 

 

That's understood...my point is that FSX can drive VRAM usage far above what's actually used directly by FSX (and what's used directly is the only part that impacts VAS usage). So it appears we're in violent agreement on that...

 

 

 

We are, but it's a point worth making because it's often claimed otherwise.

 

I realize this is really not a relavent discussion for P3D, since we are are dealing with DX11, but I'm not sure I understand the difference of a DX9 application such as FSX having to shadow the Vram being used in its own address space yet the used Vram  is not  "counting against the VAS" of FSX in DX9.  If the Vram usage is say 1 gb, isn't that (theoretically speaking) 1 gb that FSX itself cannot use for other things because it has to mirror that within it's own address space?  Again, only a side discussion, but just for my education, can somebody clarify the distinction?

I realize this is really not a relavent discussion for P3D, since we are are dealing with DX11, but I'm not sure I understand the difference of a DX9 application such as FSX having to shadow the Vram being used in its own address space yet the used Vram  is not  "counting against the VAS" of FSX in DX9.  If the Vram usage is say 1 gb, isn't that (theoretically speaking) 1 gb that FSX itself cannot use for other things because it has to mirror that within it's own address space?  Again, only a side discussion, but just for my education, can somebody clarify the distinction?

 

No because most cards limit how much address space they take up to 256mb or something similar.

 

The bottom line is the sooner the conversion to 64 bit happens the better.

 

The sooner it happens, the sooner I'll try P3Dv.?

I realize this is really not a relavent discussion for P3D, since we are are dealing with DX11, but I'm not sure I understand the difference of a DX9 application such as FSX having to shadow the Vram being used in its own address space yet the used Vram  is not  "counting against the VAS" of FSX in DX9.  If the Vram usage is say 1 gb, isn't that (theoretically speaking) 1 gb that FSX itself cannot use for other things because it has to mirror that within it's own address space?  Again, only a side discussion, but just for my education, can somebody clarify the distinction?

 

No, it's not relevant for DX11 apps.

 

Basically, if FS9/FSX (both DX9 apps) push 800MB to the video card via the frame buffer, then that 800MB of mapped frame buffer memory comes out of the 4GB VAS pool that FS9/FSX swims in.  But the VRAM use (remember that VRAM resides in the GPU itself) will include the 800MB from the frame buffer, plus a lot of VRAM used internally by the GPU to do a lot of processing.  With really high AA/AF settings (all of that processing happens internally in the GPU), you might see close to 2GB of VRAM in use looking at a GPU monitoring utility.  800MB of that VRAM is directly attributable to the frame buffer (and there's a shadow copy of that in system RAM, in effect blocking 800MB of FSX's VAS), and the other 1200MB is being used internally by the GPU for AA/AF post-processing and rendering.  That 1200MB is not shadowed in system RAM and doesn't affect the VAS, which is what Gerry was saying.

 

Clear as mud?

 

 

 

The sooner it happens, the sooner I'll try P3Dv.?

 

As long as you understand that you'll have to procure all new add-ons since the ones compiled for 32-bits will not run.

 

Regards