Another 680 owner here. Somehow FFTF tweak worked and I am getting very smooth performance with medium-high scenery settings + cloud (10000m) and VC shadows. But, I gave up on triple monitors. It's on single monitor (1920x1080) now.

 

P3dv2 is banging GPU harder than I thought and Gtx 680 simply doesn't have horsepower. The moment I switch to triple monitors, GPU usage jumps to 99% and fps instanly drops to 1/3 refresh rate (vsync on). On the other hand CPU usage is substantially low compared to fsx/p3dv1. My cpu is overclocked at 4.5ghz and I see 70-75°C cpu temp all the time when I fly with fsx/p3dv1 but it's barely going over 55°C with P3dv2.

No sim is perfect.

 

P3D is probably the best in terms of features but it still has it's problems. We still have to spend a few hours tweaking, and we still get blurries and stuttering, the odd CTD here and there, and so on. No doubt some people will say it's perfect, and perhaps it is for them, but there are plenty of posts that prove otherwise for the majority.

 

They also have no immediate plans for 64bit which in my opinion is a mistake. Regardless of improving VAS usage, a native 64bit app will always run faster on a 64bit CPU with a 64bit OS. I can understand why they haven't though, as likely most, if not all, addons would simply stop working considering their reliance on 32bit DLL's. If that day ever comes I suspect it will be with v3.

 

Then we have X-Plane which has super smooth flight with almost no tweaking. No blurries, no stuttering, and very few crashes. But it lacks a whole lot of features that understandably, users have become used to with FS9 and beyond. It also requires a metric tonne of VRAM.

 

As simmers we should be grateful for LM's hard work, but at the same time, as customers, we should be demanding better (in the nicest way possible of course).

 

Thanks for reading!

When you turn off tessellation, doesn't that move terrain paging back to the CPU and disable the dynamic lighting? That would make Prepar3D 2.2 as CPU-bound as FSX.

 

My sense is that P3D V2.2 has become more CPU bound than 2.0/2.1, presumably related to the approach used to improve the issue w/ VAS use.  I say this because of a couple of observations that I don't think can be dismissed wholesale:

• Using GPU-z, VRAM use now rarely even gets to 2Gb, whereas in prior release of P3D VRAM use would steadily increase when in the highest demand metropolitan areas all the way up to the full 6Gb on my Titan.  This does not occur now from my experience.
• Performance in those high demand areas, even in ultra-easy to process aircraft (same ones used by me in 2.0/2.1), has trouble keeping frames in the high teens and low 20's, whereas it was significantly higher in 2.0/2.1 for me.  During these of lower FPS times, reported 'GPU Utilization' (GPU-z) now rarely moves higher than 58% or so, more likely stays around 35-50%, whereas CPU utilization on the main thread is pegged at 100%.   The acid test for CPU-boundedness arguably isn't the reported 100%, but is confirmed when increasing the overclock to the CPU ends up generating a commensurate increase in frame rate--and it does in this scenario.  In 2.0/2.1, one could easily increase reported GPU utilization up to 99% by changing certain sliders, AA settings, or for example shadow quality, and other.  Right now I can turn shadows completely off while flying around LA Area, and reported GPU utilization doesn't change at all, nor does frame rate.  That seems to point to CPU-boundedness.

GPU utilization in GPU-z does correctly well w/ other surrogate markers for the amount of processing the GPU is performing:  when GPU-z reports high use, you see reported core temp go up, fan speed go up, %TDP go up, etc, and when GPU 'utilization" decreases you see a commensurate drop in those other markers.

 

This observation, in particular the cap on VRAM use, certainly begs the question of how the architecture was changed in 2.2 in order to improve VAS depletion issue.   Also, it seems it would be quite possible and indeed must be the case that the developer designs for the best performance given the typical hardware that will used to run it, so it may be that high VRAM video cards really aren't exploited w/ the current engine.   OTOH, that doesn't seem compatible w/ LM's stated mission for the platform, which I would assume would in some ways demand adequate scalability.   Who knows if GPU-z's displayed VRAM memory use may not be very reliable an indicator of how much VRAM is optimal for P3D.  As I say though it was common in complex areas to see nearly all 6Gb in use.  

 

I did the patch update to 2.2 so perhaps my experience isn't what others are seeing. 

No, I see the above as well, and from my limited testing scenery complexity seems to have the most effect on CPU usage. As you rightly state, the main CPU core is pegged at 100% in dense urban areas that have a lot of custom scenery. I've found no other slider that helps other than setting scenery complexity to below Normal. Considering this is scenery I would expect this to be offloaded to another core or even the GPU, but this doesn't seem to be the case.

 

There is definitely improvements to be made and I'm sure LM know this.

 

 

Somehow FFTF tweak worked

Can some kind soul enlighten me on how to apply the FFTF tweak.  I would like to give that one a try.  Thanks.

Can some kind soul enlighten me on how to apply the FFTF tweak.  I would like to give that one a try.  Thanks.

 

[MAIN]

FIBER_FRAME_TIME_FRACTION=n 

 

n = 0.01 - 0.99

Default = 0.33

Suggest for P3Dv2 = 0.1 - 0.2

 

Your mileage may vary. As always, I recommend you google this tweak to understand exactly what it does before diving in blind.

I will have to try FFTF again. I messed around with that last week but could not see any difference.

Performance in those high demand areas, even in ultra-easy to process aircraft (same ones used by me in 2.0/2.1), has trouble keeping frames in the high teens and low 20's, whereas it was significantly higher in 2.0/2.1 for me. During these of lower FPS times, reported 'GPU Utilization' (GPU-z) now rarely moves higher than 58% or so, more likely stays around 35-50%, whereas CPU utilization on the main thread is pegged at 100%. The acid test for CPU-boundedness arguably isn't the reported 100%, but is confirmed when increasing the overclock to the CPU ends up generating a commensurate increase in frame rate--and it does in this scenario. In 2.0/2.1, one could easily increase reported GPU utilization up to 99% by changing certain sliders, AA settings, or for example shadow quality, and other. Right now I can turn shadows completely off while flying around LA Area, and reported GPU utilization doesn't change at all, nor does frame rate. That seems to point to CPU-boundedness.

I haven't much used p3d v2.0 or v2.1, so I cannot comment on that. However, from a fresh v2.2 I also see that my CPU is clearly the bottleneck in my system. The main thread is indeed pegged at 100%, with the other cores not higher than 30% most of the time. Changing settings does not really do a lot, since most have an impact on the GPU.

Noel, very interesting observations. This seems kind of weird, considering that most of the vegetation autogen work was moved to background threads and the GPU.

 

Your experience matches the observations in the post by SolRayz (urban areas causing a big performance hit), but did this also happen in 2.0 and 2.1? If yes, then we will probably have to wait for the buildings autogen to receive the same optimisations.

 

I agree that there's still a lot they can do. Much of the workload is still handled by the main thread, background threads need more work.

I get significantly smoother performance in heavy autogen areas such as YVR in P3D than in FSX+DX10 (with years worth of tuning). And this is still with HDR, cloud and terrain shadows on at 10K, and autogen density at very high.

 

In FSX I could feel the CPU bottleneck when approaching a busy airport, whereas it seems much less noticeable now in P3D, even with the eye-candy. AA is the still one thing I'm hoping to see improved, but I'm sure that will come in time.  

 

BTW, I'm also running a 680.

 

Agree , well to some point. For me P3D is stuttering when in low 20´s which never accour in same way with FSX in DX10. 

 

FTX Regions is taking 1/3-/1/4 of my fps so is your performance with PNW ? What plane and what FPS are you getting with the above settings ?

 

Michael

Each machine and conf is a machine and conf - that's for sure...

 

In my case, with the low / med system in my PC specs, I get much better performance than I did in fsx, with or without the fixer, and also better looking graphics.

 

My only "problem" is that enabling cloud shadows has quite an impact, and so, that's a feature I do not have enabled right now...

 

 

but did this also happen in 2.0 and 2.1? If yes, then we will probably have to wait for the buildings autogen to receive the same optimisations.

 

Not to the degree it's happening now I'm pretty sure.  I can make the GPU utilization go up to max (not VRAM use at all now) by adding cloud distance when in heavier weather, but there just doesn't seem to be exploitation of the GPU for managing complex scenery as, IMHO, there needs to be.  Flying into dense autogen (I'm at DENSE, as I used in 2.0/2.1) in any kind of cloudy weather is out of the question now.  That is the guaranteed prescription for severe GPU-related frame rate degradation--the kind that 2-way SLI'd Titan Blacks will hardly get at.  It's all a bit of a balancing act but for me the balance for utilizing the GPU needs to be skewed more towards helping w/ complex scenery first, then effects like cloud shadowing after that.  One can always turn off cloud shadowing, but hopefully you are correct in pointing towards autogen optimizations (involving the GPU) as a possible approach to what I'm seeing.

Not to the degree it's happening now I'm pretty sure.  I can make the GPU utilization go up to max (not VRAM use at all now) by adding cloud distance when in heavier weather, but there just doesn't seem to be exploitation of the GPU for managing complex scenery as, IMHO, there needs to be.  Flying into dense autogen (I'm at DENSE, as I used in 2.0/2.1) in any kind of cloudy weather is out of the question now.  That is the guaranteed prescription for severe GPU-related frame rate degradation--the kind that 2-way SLI'd Titan Blacks will hardly get at.  It's all a bit of a balancing act but for me the balance for utilizing the GPU needs to be skewed more towards helping w/ complex scenery first, then effects like cloud shadowing after that.  One can always turn off cloud shadowing, but hopefully you are correct in pointing towards autogen optimizations (involving the GPU) as a possible approach to what I'm seeing.

 

I really think that they should move the entire autogen work to the GPU, or at least as much as possible. Microsoft Flight did that, and the result was really visible. You could see a massive amount of buildings and trees everywhere without your system breaking a sweat (plus the trees had quadruple the amount of detail compared to the default FSX trees, and they also swayed with the wind). GPUs progress so quickly that in a couple of years everything will be fine. With the CPU free from the autogen workload, we can turn up the traffic sliders more (I would particularly love to see the car traffic slider get some usage).

 

We'll just have to wait and see what direction Lockheed Martin will take. If their goal is to break the tradition of Prepar3D being CPU-bound, they've still got a lot to do.

GPUs progress so quickly that in a couple of years everything will be fine.

 

Agree, and that's why we want to get performance more GPU bound than CPU bound ... in a couple of years a Titan will be <$400 and we'll be 2 generations into the next latest GPU which will probably perform 50% or more faster than a Titan.  GPU's haven't reached the same limits as CPU's (which are mostly getting more cores in the less space rather than increases in single core performance) ... GPU's will eventually start to hit limits (power and heat most likely), but for now it's still a rapidly improving technology.  Being GPU bound means you can add more GPU's (once we get SLi support) without having to completely rebuild a new system from scratch - this is a huge benefit.

 

And then there is DX12 and whatever that may bring in the future ... development is progressing rapidly on the graphics side.

 

GPU bound is where we want to be for flight simulation.

 

Cheers, Rob.

Agree, and that's why we want to get performance more GPU bound than CPU bound ... in a couple of years a Titan will be <$400 and we'll be 2 generations into the next latest GPU which will probably perform 50% or more faster than a Titan.  GPU's haven't reached the same limits as CPU's (which are mostly getting more cores in the less space rather than increases in single core performance) ... GPU's will eventually start to hit limits (power and heat most likely), but for now it's still a rapidly improving technology.  Being GPU bound means you can add more GPU's (once we get SLi support) without having to completely rebuild a new system from scratch - this is a huge benefit.

 

And then there is DX12 and whatever that may bring in the future ... development is progressing rapidly on the graphics side.

 

GPU bound is where we want to be for flight simulation.

 

Cheers, Rob.

 

Totally agree. Nobody should underestimate progress of GPUs. In a couple of years, NVIDIA Pascal will reach 1TB/s of memory bandwidth, more than 3 times the bandwidth of the GTX Titan. CPUs on the other hand... It's pretty much a monopoly handled by Intel (AMD have exited the desktop consumer market), and clock speeds aren't improving. This year they will bring out octa-core CPUs, but there are barely any applications that will use all those cores to the max.

 

The biggest "upgrade" will probably come with DirectX 12, and I think that Prepar3D 2.x has to support it as soon as possible.