But how you do know that your hardware and software combination can't run more than 50% of the GPU?

Because it's easy to force the GPU up to 100% while at the same time the CPU is at 100%, by dialing up the typical factors that influence GPU workload:  cloud shadows, shadow quality, AA, etc.  Quite obviously in the scenario I am describing it's only the CPU that's sitting on 100%, and the evidence that the CPU has become the frame rate bottleneck is evidenced by the predicted proportional increase in frame rate w/ CPU overclocking.   I think this comment from Rob hints at the basic problem, though you can substitute 'scenery' or 'airport add-on' for 'aircraft':

 

Obviously there is something in these aircraft that is causing some type of shift from GPU bound to CPU bound ... what specifically I have no idea.

 

I would doubt there is anything necessary about this issue being restricted to aircraft over scenery add ons not optimized for V2.x.  Also, one can change the autogen & vegetation sliders up or down a few notches and there will be a change, but it will be quite marginal in my system.   So to me this suggests the issue is might just be too much autogen or vegetation to process by the CPU in a given area.  I know the CPU plays a role in this process so this is a possibility.    And if that's true, then throw in a high CPU demand plane, and it would likely get very dicey and SLI will not solve this that I can see.  I think the real unknown here is just want can be expected by optimizing add ons for P3D V2.x   Rob mentions LM is working to support 3PD's to address this stuff, and I hope there's still headroom for optimizing add-on scenery, or P3D, or likely both.  In simple terms, I'd love to be able to add a 2nd Titan to improve this picture, esp when the PMDG T7 shows up, but right now I don't see a 2nd Titan adding much more than better cloud shadowing and modest improvements in AA.  I would not add a 2nd Titan for this alone.  Seems like we should know more and soon about this very issue.

Because it's easy to force the GPU up to 100% while at the same time the CPU is at 100%, by dialing up the typical factors that influence GPU workload: cloud shadows, shadow quality, AA, etc.

But then you've changed the "hardware and software confimation" so my point remains - it still can't run more than 50% of the GPU.

But then you've changed the "hardware and software confimation" so my point remains - it still can't run more than 50% of the GPU.

Sorry that sound a bit tautological to me...

Well I've moved to back SGSS AA (NI) now and using my Affinity of 2388 is working very well for me, even during Dusk with clouds passing between the sun.  However, A LOT of clouds will still stress out SGSS AA setting.  Made a few other adjustments, but these settings are working well for me: http://www.robainscough.com/Prepar3D_Settings_2.html

 

At first I thought CPU frequency change (i.e. from 4.2Ghz to 4.8Ghz) would do nothing ... but once again I'm proven wrong, certain locations/situations will enjoy higher CPU frequency while others will not be impacted at all by higher CPU frequency.  So this tells me some aspects of a "scene" are more CPU bound than others ... could be Auto Traffic, could be AI traffic, could be just building density, could be Vectors roads, rivers, power lines, etc. etc. 

 

I still want full SLi support, because I think as time progresses and more is learned about P3DV2.x from 3rd party content providers, the more we'll see the shift to GPU as optimization are figured out and implemented.

 

Cheers, Rob.

 

P.S.  In the mean time I keep flying ... trying to get one flight in every other night if possible and I'm really learning/enjoying the experience.

Well I've moved to back SGSS AA (NI) now and using my Affinity of 2388 is working very well for me, even during Dusk with clouds passing between the sun.  However, A LOT of clouds will still stress out SGSS AA setting.  Made a few other adjustments, but these settings are working well for me: http://www.robainscough.com/Prepar3D_Settings_2.html

 

At first I thought CPU frequency change (i.e. from 4.2Ghz to 4.8Ghz) would do nothing ... but once again I'm proven wrong, certain locations/situations will enjoy higher CPU frequency while others will not be impacted at all by higher CPU frequency.  So this tells me some aspects of a "scene" are more CPU bound than others ... could be Auto Traffic, could be AI traffic, could be just building density, could be Vectors roads, rivers, power lines, etc. etc. 

 

I still want full SLi support, because I think as time progresses and more is learned about P3DV2.x from 3rd party content providers, the more we'll see the shift to GPU as optimization are figured out and implemented.

 

Cheers, Rob.

 

P.S.  In the mean time I keep flying ... trying to get one flight in every other night if possible and I'm really learning/enjoying the experience.

 

Hi Rob,

 

I decided to go thru the 3h hassle of uninstalling everything right on thru EMT & P3D V2.21 as my entire installation was done using patches up until this morning.  It turned out to be wasted time unfortunately, which I think is a testimony to just how well the patches & their install instructions are.

 

What I have realized is that NCA in the Bay Area is just plain hard on frames and indeed the CPU gets squashed pretty strongly there, at least w/ that fav of mine the RA T Duke.   Everywhere else in NCA is peachy, so I think it will be a case of unchecking Hybrid mode if I'm going to fly something other than very light default planes out of KSFO or similar places in the NCA metro areas.    Still haven't loaded the MD80 but that's coming later.

 

Yes I hope too that there is room for more optimization w/ more collaboration between ORBX & LM.  Intuitively (aka, I don't really understand what's involved) it seems a pity to not see that GPU ramped up to 100% in the SF Bay Area in NCA--I would be lobbying for SLI'd Titan right away.  Fortunately the sim performs marvelously in lesser, non-regional areas.

 

Perhaps as a interim solution maybe I should pick up Vector and hold off on installing PNW, though it ran well as long as I was careful around the heavy areas like KSEA.  I know your sense is that Vector doesn't come w/ a huge penalty or so can be configured thus.

 

One huge annoyance for me is REX4's lack of ability to decide WHICH particular category of textures to install in a given install, whereas w/ REX E+ one could select which category of texture to install.  I would really like to have NOT overwritten water textures as the default one for P3D in some ways is better than the REX4 ones ;o(   REX really hosed their installer (I'm not saying anything about their method now of rapid install of textures that is truly awesome, but the fact you can't deselect which categories of textures is heinous).  I really hate when something is done very very well (Office 2003 for example), then it is 'upgraded' only to muddle the picture or lose very useful features.

 

 

at least w/ that fav of mine the RA T Duke

 

RealAir's Duke is a big frame rate killer for me - especially prop animation seems to really impact FPS (start up the aircraft and I drop 5-7 fps) ... but in there defense, it's not designed for P3DV2 and doesn't even have installers for it and I don't "think" RealAir have committed to any products for P3DV2 ... guess they are on a "wait and see" pattern.  There is a pretty big variance between the Duke and the A36 in terms of fps (almost a 15 fps difference).

 

Vector is going to be harder on your setup ... especially traffic settings.  Agree, KSEA is hard on performance ... I dialed my Building density back one notch to "Dense" rather than "Very Dense" ... seems to have helped.  Oddly Vegetation Extreme or Dense makes no difference in fps ... but building density does ... hmmm.  

 

Well ... I'm not sure you got the implications behind my comment of co-operation with 3rd party and existing products ... adding a lot of code to accommodate legacy products will have a negative impact on performance in some cases (lets just say the code they've added to support legacy isn't helping out performance, it's there for compatibility).  For example, if there is code that says render this object using this method because it's been identified as legacy, then every time you build the object in the scene you have to execute the decision branch which will consume processing cycles vs. an object where you don't have do a branch.

 

Agree, would like to see REX 4 Texture updpate that will allow us to easily retain and adjust using default textures vs. REX textures ... hopefully someone (or several) has made this a feature suggest for future REX 4 update?

 

Anyway, I'm back to crazy overclocking now as it does seem to make a difference in some areas/situations.

 

Cheers, Rob.

Ok... so I did some playing around in the LA basin area with Prepar3D v2.2.

 

I found that my frame rates stayed above 25fps while locked at 30fps. I found that I could crank up the scenery sliders themselves to maximum without any significant performance issues. I found out the amount of clouds combined with cloud shadows directly impacted performance. I did all of this flying the Cessna 172 from FSX with the Mindstar Aviation G1000 in it.

 

Now, on to discuss performance numbers themselves.

 

My settings:

FXAA: On
MSAA: 8 Samples
Texture Filtering: Anisotropic 16x
Texture Resolution: Ultra - 4096x4096
Tessellation Enabled
Resolution: 1920x1080x32
VSync: On
Triple Buffering: Checked
Target Frame Rate: 30


Level of detail radius: Max
Tessellation Factor: Ultra
Mesh resolution: 1m
Texture resolution: 7cm
Land detail textures: Checked


Scenery complexity: Very Dense
Autogen vegetation density: Extremely Dense
Autogen building density: Normal


Water Detail: Ultra
Reflections: Clouds User Vehicle
Special Effects Detail: High
Special Effects Distance: Medium

Landing-lights illuminate ground: checked
Lens flare: checked
HDR Lighting: checked
Shadow Map Count: Ultra
Enable Terrain to Receive Shadows: checked
Terrain Shadow Cast Distance: 0m
Cloud Shadow Cast Distance: 10,000m
Object Shadow Cast Distance: 3,000m
Internal Vehicle: Cast - Receive
External Vehicle: Cast - Receive

First and foremost, if for absolutely any reason you firmly believe a GPU should always be pegged at a 100% load when flying in Prepar3D v2.2, then I'll simply ask you to read all of what I have to say before commenting.

 

What I found as I flew around was that the complexity of the 3D scenery directly impacted the GPU load. The more complex, the higher the load. The less complex, the lower the load. The load was directly proportional to how much GPU power it took to render a physical frame. So, in short, the less GPU power needed to render a single physical frame, the lower the GPU load is going to be. If your GPU can render 30fps at 50% GPU load... then you won't see the load value higher. It is what it is and has nothing to do with programming but rather more to do with the power of the GPU itself.

 

On my system I averaged a 50% GPU load. I also averaged a 50% CPU load.

 

I could get more CPU load by enabling photoscenery, which forced the CPU to constantly fetch textures for rendering to the terrain.

 

I could get more GPU load by changing the weather so that there were more clouds in the sky. The amount of clouds had a significant impact and using ASN with this was the way I tested that behavior. I do not recommend using 20 cloud layers in a thunderstorm. LOL

 

In the end what I saw was exactly what I expected to see. All scenery sections that have been optimized to take advantage of the GPU did so... and any scenery that wasn't designed with that in mind... forced the CPU to do more work.

 

However, at no point did the aircraft itself become a factor.

 

 

However, at no point did the aircraft itself become a factor.

 

Interesting, my testing results show the aircraft to be a significant factor but not the only factor ... however the complexity of the aircraft wasn't a factor (i.e. QW RJ100 with FMC was performing the same as A2A's C-172 in terms of fps).

 

I used the same location in every test (saved flight), testing was done as follows:

1.  Set airport to KCCR

2.  clear weather

3.  set time of day (2pm 4/15/2014)

4.  load A36 (aircraft that comes with P3D)

5.  Start aircraft (important step)

6.  Save Flight

7.  Exit P3D

8.  Load A36 Flight

9.  Log frame rates (do not move anything)

10.  Load next Aircraft to test

11. Save Flight 

12. Exit P3D

13. Load Flight 

repeat steps 9 thru 13 for each aircraft

 

Results from my testing process showed a significant variance from aircraft to aircraft ... as much as a 75% difference in some cases.  The Carenado Phenom vs. A36 for example, it's performance variance was directly related to having the MFD/PFD's powered on or off.  I can make a video of the difference in aircraft if you like with the fps displayed clearly and demonstrate how the MFD/PFD impacted fps in the Phenom.

 

But I do agree with you on the CPU/GPU load values ... they don't mean much to me other than something is happening, their % values just aren't qualified.

 

Beau made some observations that some things appear to be CPU bound when they should be GPU bound but I haven't heard any further expansion on that.  I've seen many threads saying that are 100%, 75%, 50% utilization ... but I always appear to be around 20% on the GPU side regardless of graphics settings ... which is why I don't take much value out of these GPU monitoring tools.

 

Cheers, Rob.

 

 

First and foremost, if for absolutely any reason you firmly believe a GPU should always be pegged at a 100% load when flying in Prepar3D v2.2, then I'll simply ask you to read all of what I have to say before commenting.

 

I've found that the optimal place for GPU is somewhere around 85-90% ideally.   Actually, 99% is fine, it's just that >99% can cause a massive choke, so one needs a little headroom to cope w/ those situations when too much stress on the GPU is a possibility.  It's quite easy to set up somewhat static situations so that this works well, i.e. when the weather remains somewhat constant over the course of your flight.  When the sim gets bogged down from CPU-boundedness, the GPU load becomes secondary.  Hopefully these can be balanced more, especially when full SLI comes.

And if your GPU is running at 99%... that means it is at it's limit and can't render any more.

 

I think your expectation for how much load a GPU should be showing is inaccurate.

 

I was able to change the load on my GPU by changing the complexity of the 3D rendering in Prepar3D. Think about that.

And if your GPU is running at 99%... that means it is at it's limit and can't render any more.

 

I think your expectation for how much load a GPU should be showing is inaccurate.

 

I was able to change the load on my GPU by changing the complexity of the 3D rendering in Prepar3D. Think about that.

And when your CPU is running at 99%...that means it is at it's limit and can't calculate anymore. Right? :lol:  

And when your CPU is running at 99%...that means it is at it's limit and can't calculate anymore. Right? :lol:

You're trolling.