4 hours ago, djbully said:

I’m not sure about that. I’ve oom’d with 16gb Vram in v5. With lots of addons, high settings, full aigaim AI and heavy weather with TEXTURE_SIZE_EXP=10 tweak it’s easily done.  

Sir, I do not believe you should be using the texture size exp tweak in P3Dv5.  That was done in v4 to allow 1024x1024 terrain texture size, which is the default for v5.  I have had that tweak in v4 for over a year with 11GB VRAM and when I ran out of VRAM (4096 textures with Orbx Honolulu Cityscape) it simply turned into a slide show.  No OOM.  In fact, I've never seen an OOM in P3Dv4 or 5 and only time they are reported in forums is when someone has tried to adjust their pagefile memory.

13 hours ago, downscc said:

I don't know where you are getting this patently false information, but you should question that source.

One of the major advantages to DX12 Video API is that is allows the application to manage VRAM instead of the OS and changes to Win10 in early 2020 gave it a full capability compatible with the video driver and the OS.  Prepar3D v5.1 takes advantage of this capability to manage VRAM.  It will adjust to cases where VRAM allocation is high and you will never exceed the VRAM capacity.  Not even DX11 and earlier would result in OOM errors if you exceed VRAM because the NVidia driver will simply start using the system drive as a cache for the overflow and the result is a slideshow not an OOM.  I've seen this happen in P3Dv4.5 to me with 11GB VRAM.

If you use the Shift+Z shortcut to display the frame rate you'll notice in P3Dv5 that is also displays the amount of VRAM used and the amount that it has available.  If you have 8GB the available will be less because the video driver needs work space.  My 11GB card runs about 9.3GB available (from memory) and normal allocation in heavy scenery areas runs up to 6GB.

I was under the impression from LM and other various developers that te dx12 api puts the onus on the application developers to control the memory vs a built in driver level function running in dx11. Hence in dx11, the driver natively swapped vram for system ram when needed, but dx12 does not automatically do it. It has to be coded in by the developers of the application. P3DV5 wasn’t the only dx12 title that is/was a victim of this. Vulkan Xplane had a terrible time in beta and release now for the same issue.
 

V5 launched with no application level support for this and then had the “dynamic texture streaming” option added after all the reports of OOM errros. I don’t personally use it but I believe the results are very mixed as to how well it works and the results. A simple search here on Avsim shows the questionable results.

Anyhow OP it’s hard to say why you don’t see a performance increase...could be a myriad of issues such as a capped frame rate already etc etc. I can say in 4K I have a pretty massive uptick in performance in v5 vs v4 even though I have my texture size turned down to keep from oom crashes.

I am a P3D beta and I assure you there is application support for VRAM management, improved in 5.1, and continuing improvement.  All of my display sliders are full right and I use high resolution textures, and I've never exceed my 11GB VRAM.  A simple search here on AVSIM reveals the same thing any web based public forum will reveal.... lots of opinion and very little fact.  LM was able to include VRAM management in V5 because not only did they move to the DX12 API but they also created a new rendering engine, finally leaving much of what was once ESP.

Of course DX12 doesn't swap to cache by itself, in Windows 10 if the application is not controlling VRAM then the OS is... it's that way by design.