You all should switch to DX10! I did it 2 days ago and didn't had any OOMs. I've just completed a flight from KFJK to KLAX in DX10. Most sliders to max, AI on 60%, TML2048, with the PMDG 777. VAS was around 3,6 on landing. FPS around 20 at JFK and LAX.

You all should switch to DX10! I did it 2 days ago and didn't had any OOMs. I've just completed a flight from KFJK to KLAX in DX10. Most sliders to max, AI on 60%, TML2048, with the PMDG 777. VAS was around 3,6 on landing. FPS around 20 at JFK and LAX.

DX10 helps prevent OOMs?

 

That is new for me!

 

As far as I know:

FSX OOMs because it is a 32bit App and as such it has a VAS limit of 4GB. Switching to DX10 does not change that FSX is still a 32bit App.

 

DX10 takes some of the load away from the CPU, moving it to the GPU. So this should make it easier to achieve the magic 30fps.

I don't know that either. But VAS is such a big problem that understanding it might be beneficial.

Well, the Topic Starter said BP=0 freed up some VAS for him. I dont like ussing BP=0 so instead I used something similar but without risking graphical glitches and without the need to run set "Water at High x2"

 

Maybe someone else understands this better:

http://www.sim-outhouse.com/sohforums/showthread.php?34661-Thank-you-*******-*******-Altuve-that-is-*-FSX-Important-*

 

But I conclude

With BP=0, the CPU instructions are send directly to the GPU

With BP=1, the CPU instructions go to a middle man first, also called application managed Buffer or Explicit Vertex Buffers.

 

Now if Explicit Vertex Buffers are the same as VAS then that would explain how reducing BP reduces VAS.

 

So the question is, are Explicit Vertex Buffers the same thing as VAS?

 

What I also understand from this is that BP=0 can cause problems.

If the CPU sends to many instructions to the GPU you can get flashes, stalls and crashes.

With the BP method I use that seems not to be the case which is why many call it safer I guess.

Hey Rob, those are interesting questions. I was thinking again about your test with the windowed/full screen mode so tried it myself under better testing conditions than I did before. I set up a flight with the PMDG 737 at FSDT CYVR with Orbx and UT etc. and a weather theme so the weather would be constant. Then I saved and started it again first in windowed mode then in full screen mode. In both cases I taxied out to RWY26R and took off and as soon as I hit 2500ft I did ctrl-alt-del to bring up task manager and then Process Explorer. In windowed mode I was at 3.1GB VAS and in full screen mode I was at 2.9GB VAS. That's a significant difference in VAS.

Well yes....but I think you would have to test several times because even two identical flight in FSX are different each time. (you know, clouds change, your flight path wont be exactly the same, etc)

 I dont like ussing BP=0 so instead I used something similar but without risking graphical glitches and without the need to run set "Water at High x2"

 

 

The demands of water x2 are mitigated by the increase in performance courtesy of BP=0 though. If you have a CPU at 4.4 GHz, as you say, water at high 2x shouldn't be an issue.

 

Graphical glitches for me only occurred when the frame rate lock was very high, and Autogen was very high. Dense Autogen is fine.

 

As for VAS, I know absolutely nothing about it, I've never had an OOM in my life. I do understand that for you guys with demanding scenery and airport add-on's it's a different ball game.

 

 

What I also understand from this is that BP=0 can cause problems.

If the CPU sends to many instructions to the GPU you can get flashes, stalls and crashes.

With the BP method I use that seems not to be the case which is why many call it safer I guess.         

 

 

 

Yes, I used to use a reject threshold instead of BP=0. However, when I cottoned on to the fact that a minor setting reduction cured all artefacts I went back to BP=0. Glad I did, in a heavy weather scenario I see a 40% increase in performance.

 

If you haven't tried BP=0, you should. It's well worth a minor reduction in slider settings.

DX10 helps prevent OOMs?

 

That is new for me!

 

As far as I know:

FSX OOMs because it is a 32bit App and as such it has a VAS limit of 4GB. Switching to DX10 does not change that FSX is still a 32bit App.

 

DX10 takes some of the load away from the CPU, moving it to the GPU. So this should make it easier to achieve the magic 30fps.

 

Where do I say that DX10 makes FSX a 64bit App? I just say that switching to DX10 gave me significant lower VAS without lowering AI, sliders, TML etc... So yes, it helped me prevent OOMs. 

Can anyone else confirm that running FSX in Fullscreen will lower your VAS?!?!

Where do I say that DX10 makes FSX a 64bit App? I just say that switching to DX10 gave me significant lower VAS without lowering AI, sliders, TML etc... So yes, it helped me prevent OOMs.

 

And where did I say, that you said, that FX10 changes FSX into an 64bit App??

 

Relax dude, no need t get all defensive!

 

You input was appriciated.

The idea that DX10 helps prevent OOM,is new to me.

Its the first time I hear that.

I mean it just like that, no need to interpret anything into it.

I think what you're observing is an effect of the Direct3D device being reset as you switch between fullscreen and desktop. Whenever you do this, Direct3D has to purge all of its state and texture memory, reinitialize and load them back in again (that's why you get that longish pause when toggling between modes). Since there is texture caching going on behind the scenes, I suspect that when you reset the Direct3D device like that, you observe a momentary drop in memory usage as those cached textures are freed from RAM. It takes time for those caches to refill. To really test this theory, you would need to fly around for a period of time and compare (fly for 10 minutes in a scenery area in windowed mode...then switch to fullscreen and fly around for 10 minutes and compare your VAS). I suspect they will eventually settle out to about the same.

After some more testing, I think this is correct. The reduction of VAS seems to be short lived!

 

I could not test this before because the Process Explorer kept crashing on me when I returned from fuellvscreen to windowed mode.

 

Now that I put in Affinitymask=14, the explorer does not crash anymore!

 

What does that mean by the way...that I need an FSX tweak to stop Process explorer from crashing?

Can anyone else confirm that running FSX in Fullscreen will lower your VAS?!?!

no seems to be temporare now :-(. But try Bufferpools.

 

Either BP= 0 with Water High x2 and reduced Sliders in case of graphic flashes/glitches,

 

or, if you want to keep your slider settings amd run Water lowx2

 

[bUFFERPOOLS]

UsePools=1

Poolsize=8388608

RejectThreshold=262144

 

96Kb = 98304

128Kb = 131072

256Kb = 262144

512Kb = 524288

Yes, I used to use a reject threshold instead of BP=0. However, when I cottoned on to the fact that a minor setting reduction cured all artefacts I went back to BP=0. Glad I did, in a heavy weather scenario I see a 40% increase in performance.

 

If you haven't tried BP=0, you should. It's well worth a minor reduction in slider settings.

Thx for your input!

 

I tried it (with Water Low x2) yesterday but saw now difference between BP=0 and the reject threshold way.

 

I did not see graphical glitches either with BP=0 but I guess I need to test a bit more to run into conditions that cause problems.

 

Also this was with fair weather. I will try again with poor weather.

 

By the way, does using OPUS live weather also increase FSX VAS?

Opus shouldn't increase VAS as it's an external program to FSX. Even if an increase in VAS when switching to full screen is shortlived, for those of us who fly in windowed mode and get the odd OOM on final into a complex airport this could be a great "fix."

Wait does Bufferpools and usepools are the same isnt it ?

 

Also this was with fair weather. I will try again with poor weather.

 

 

 

For what it's worth...

 

With clear weather I see absolutely no benefit from BP=0.

 

But with, for example, FSX grey and rainy scenario, that's when I see a huge increase. Seems to me that the GPU has to be actually be under load due to REX clouds etc. before the improvement is manifest.

Ok, thx Martin.

 

I will try in a few days.

Work keeps interupting my simming hobby!

For what it's worth...

 

With clear weather I see absolutely no benefit from BP=0.

 

But with, for example, FSX grey and rainy scenario, that's when I see a huge increase. Seems to me that the GPU has to be actually be under load due to REX clouds etc. before the improvement is manifest.

 

I completely agree. Although I think it's the CPU under load (or rather the performance asymmetry between the GPU and CPU) that's key since the buffer pools reside in system RAM not VRAM. I found in my testing that the GPU appeared stuck waiting on the CPU most of the time. The CPU has to yield simulation cycles while pages of system ram are locked and shuttled from the pool across the bus to the graphics adapter. If you have a sim like the T7 that is computationally intensive and it's operating in adverse simulation conditions (photorealistic scenery, high poly count, bad weather w/ lots of clouds, etc) the stalls caused by texture and geometry data transfers can start to rob the CPU of simulation cycles. If on the other hand, during the rendering pass if you can "get in and get out" quickly and write directly to video memory you don't surrender those simulation cycles. The CPU is now free to do what it does best: simulate. The GPU can do what it does best: draw. And they do it independently of the other. The moment you introduce contention, somebody is inevitably waiting on somebody - it doesn't matter who...the result is the same.

 

If you're flying a sailplane in clear weather, with 10nm vis, at 1000' AGL there is no load on either CPU or GPU, there's no contention for system resources, so the performance effect of enabling or disabling the pools cannot be observed.

I completely agree. Although I think it's the CPU under load (or rather the performance asymmetry between the GPU and CPU) that's key since the buffer pools reside in system RAM not VRAM. I found in my testing that the GPU appeared stuck waiting on the CPU most of the time. The CPU has to yield simulation cycles while pages of system ram are locked and shuttled from the pool across the bus to the graphics adapter. If you have a sim like the T7 that is computationally intensive and it's operating in adverse simulation conditions (photorealistic scenery, high poly count, bad weather w/ lots of clouds, etc) the stalls caused by texture and geometry data transfers can start to rob the CPU of simulation cycles. If on the other hand, during the rendering pass if you can "get in and get out" quickly and write directly to video memory you don't surrender those simulation cycles. The CPU is now free to do what it does best: simulate. The GPU can do what it does best: draw. And they do it independently of the other. The moment you introduce contention, somebody is inevitably waiting on somebody - it doesn't matter who...the result is the same.

 

If you're flying a sailplane in clear weather, with 10nm vis, at 1000' AGL there is no load on either CPU or GPU, there's no contention for system resources, so the performance effect of enabling or disabling the pools cannot be observed.

 

 

Interesting theory. I'm not expert enough to make any claims regarding it's veracity though.

 

For me, I just look at it simplistically.