For the uninitiated the Super MD80 Pro is ultra, I mean ultra, frames-friendly.   Pushback thru ready for TO on RWY28L frames moved between 24 and 27.  Rolling down the runway for TO frames got all the way down to 20.   I have vegetation & autogen at Dense.  Clockspeed at 4.42Ghz in the SB-E, GTX Titan.  Out of NCA, at KSBA for example at dawn in this plane w/ 3D light blazing thru FTXG, frames in the MD80 sit around 45 or so w/ similar clouds.

 

In V2.2 my GPU during this time is showing 45-50% utilization, CPU Core1 100% and the other 5 cores doing what they would be predicted to do.  The sim was not smooth as frames dipped down below 24 or so.   What needs to happen to get some of this processing on to the GPU?   There's a lot of processing power sitting unused.  I do find GPU-z's reporting of GPU Utilization is completely compatible w/ the other reported surrogate markers for processing demand on the GPU:  for example, fan speed, temp %TDP, all suggest the Titan was lugging along hardly being used.

 

I can't imagine SLI will help this at all, can you?  This appears to be just plane raw CPU-boundedness and I can't imagine what a PMDG product would do in this.   Dialing back autogen to sparse frames went up 2 points, that's it.   Is the argument that devs like FB & ORBX need to optimize this more?  Right now, it's hardly useable and again a complex bird I would imagine would perform terribly.

 

 

 Right now, it's hardly useable and again a complex bird I would imagine would perform terribly.

 

 

Right now, after seeing your postings here and at the Prepar3D site you would probably be better returning to FSX. It would appear that nothing Lockheed does will match up to your expectations.

 

Maybe even consider getting and using FS2004. Seeing 100 fps appears to be the objective, with all sliders right, of course. You might find happiness using FS2004.

 

 

In the mean time, I will be happy for mostly high settings and 25 fps average. I am not engaged in a contest with anyone on the highest FPS, so I guess my level of satisfaction comes in at a lower point than others.

Too bad you couldn't focus on the questions in the post, and instead proceeded to put all your effort towards invalidating the questions and issues by replying with insults and sarcasm.  

 

The question is how will SLI address this type of scenario:  when frames drop to the low 20's w/ an ultra simple to process plane in a high demand area, and there is ample unused GPU resources, what does this mean for complex planes that many folks hope to use at some point?   The value of off-loading to the GPU certainly is attractive, and one reason is that upgrading GPUs or adding add'l GPU thru SLI is a whole lot simpler than rebuilding the whole machine.  Unfortunately when the scenario becomes CPU bound and a frame level below 25 or so the smoothness starts to go, and it would seem more GPU won't help.   Get it?

 

I've made many positive comments about P3D so your comment is unbalanced and just nasty and misleading.  I'm trying to ascertain where the sim is going w/ respect to accommodating complex planes and how that relates to SLI.  Most users are using default and simpler add on planes now and as people contemplate SLI, myself included, I'm interested in finding out if there is more hope for optimization, and how much of that will need to come from 3PD's or LM.  Right now, it looks doubtful the sim will handle complex planes out of those sorts of airports and regional scenery enhancements.

 

 

In V2.2 my GPU during this time is showing 45-50% utilization

 

Is this with tessellation set to Ultra?

 

gb.

+1

 

I think your Q is really important as well. We are in the same boat most of us. (KSFO -Carenado Bonanza will give you same performance).

 

I have a GTX780 SC at 1110MHZ, not far of by that Titan of yours and really had my doubts about getting another one in SLI if the result is somewhere 15-20 fps when the PMDG´s comes to our disposel. P3DV2 does not run that smooth below 24fps i think. At least on my system there is alot of stutter below 24fps.

 

Hopefully LM will further improve the development so we can balance the raw power of the CPU and GPU.

 

Maybe 2.3 will adress it ? 

 

What about Drivers ? Anyone who have bench them ?

 

Michael

Your expectations regarding old addons designed for FSX are problem #1. It's unrealistic. Even addons I worked on for FS9/FSX show framerate hits in Prepar3D that didn't happen in the other sims... because the way we were able to code was different. There are differences and one can not simply take a complex anything for FSX and toss it into Prepar3D without some modifications. It was the same way when making the 3D models for aircraft for FSX. Techniques used for FS9 resulted in poor frame rates and things had to be done differently.

 

When new addons are made specifically for Prepar3D v2.2 and beyond, they will be created in a different manner than they were for FSX. They will have to be. They will have to break fewer "rules" (term used to describe doing things that aren't documented).

Is this with tessellation set to Ultra?

 

gb.

Yes it is.  My scenery sliders are all hard right.  HDR on.  In lesser density areas I can get the GPU up to 100% utilization when cloud shadowing is involved and all of that makes perfect sense, though it's quite possible as we all know by now to totally kill performance when you have the combination of dense clouds w/ any value over zero in the cloud distance slider.   The implication when you see is that that certainly SLI will like help in this scenario.  We're all hoping there is some more optimization coming in the cloud shadowing department, else it will be a feature one just to be very careful to use when cloud density is low.    It's been a while since I changed the tessellation slider since in past times I didn't notice any performance difference w/ it on ultra.  My assumption was that tessellation really involved the GPU only or primarily, but it's worth a shot to see if there is anything there that can be adjusted to help cope w/ both cloud shadows and the issue I am referring to above.

Your expectations regarding old addons designed for FSX are problem #1. It's unrealistic. Even addons I worked on for FS9/FSX show framerate hits in Prepar3D that didn't happen in the other sims... because the way we were able to code was different. There are differences and one can not simply take a complex anything for FSX and toss it into Prepar3D without some modifications. It was the same way when making the 3D models for aircraft for FSX. Techniques used for FS9 resulted in poor frame rates and things had to be done differently.

 

When new addons are made specifically for Prepar3D v2.2 and beyond, they will be created in a different manner than they were for FSX. They will have to be. They will have to break fewer "rules" (term used to describe doing things that aren't documented).

That was the question I posed at the end:    'Is the argument that devs like FB & ORBX need to optimize this more?'  I haven't heard of 'optimized' for P3D i.e. designed around changes to the core engine, have you?  Until the claim is made that it's even possible to add significant optimization the question remains ultra relevant, especially with what you are saying.  Further, I'm exploring the idea of SLI and what it can offer in this scenario.  I posted the question early on as to why in that same plane (it's really easy on frames and works ultra well in most all scenarios--better than default planes in some) at default KDEN showed the same phenomenon:  low GPU utilization, restricted frame rate, and CPU at 100%.   There is considerable banter about SLI and right now SLI appears to mostly address added processing involved in cloud shadowing for example.   I don't see that addressing the issue I mentioned perhaps for the reasons you state.

 

 

P3DV2 does not run that smooth below 24fps i think. At least on my system there is alot of stutter below 24fps.

 

Indeed.  In my experience there are two types of hard bottlenecks:  when the GPU is maxed by cloud shadowing for example, one can see frame rates of 20 or a little more yet smoothness deteriorates drastically to the point of absolute uselessness.  That's easy to solve just turn off cloud shadowing (or really restrict cloud density of course) until you can get a 2nd, 3rd or 4th GPU in SLI.

 

The 2nd kind is the CPU-bound kind.  This is trickier because if you've played around w/ this moving sliders only slightly helps.   This may be the generic issue Ed refers to regard unoptimized for P3D conditions.  OK, sounds reasonable.  The only problem is we don't have a clue how much optimization potential there is, do we?   

 

I decided a few weeks ago to remove FSX and did and have been very vocal that P3D is all I used since installing it months ago for all the reasons we are tickled to have it.  A few significant issues remain, and one of them indeed is how the sim will handle complex birds in complex scenery.    Right now, it looks really troublesome.  And since we haven't heard a word about what 'optimization for P3D' means, it's still uncertain.

What do you want to hear? Prepar3D 2.2 hasn't been out very long... and most FSX developers aren't doing a thing for Prepar3D at all.. so...

 

Exactly what do you expect??

 

Personally I expect that initially you will see some developers try to convince you to purchase their FSX addons for Prepar3D and then blame the sim for any performance issues you may encounter. I'm a developer, and I'm telling you this based on things I've seen in the past with regards to FS9 and FSX. There were FS9 addons relabeled for FSX and their 3D models were never touched. This resulted in performance issues with said 3D models... which was blamed on the sim, despite the fact that other developers were redoing their 3D models to address rendering the way FSX does it versus how FS9 does it.

 

You're going to have to wait and see what develops and stop attempting to draw conclusions on flawed information.

What do you want to hear? Prepar3D 2.2 hasn't been out very long... and most FSX developers aren't doing a thing for Prepar3D at all.. so...

 

Exactly what do you expect??

 

Personally I expect that initially you will see some developers try to convince you to purchase their FSX addons for Prepar3D and then blame the sim for any performance issues you may encounter. I'm a developer, and I'm telling you this based on things I've seen in the past with regards to FS9 and FSX. There were FS9 addons relabeled for FSX and their 3D models were never touched. This resulted in performance issues with said 3D models... which was blamed on the sim, despite the fact that other developers were redoing their 3D models to address rendering the way FSX does it versus how FS9 does it.

 

You're going to have to wait and see what develops and stop attempting to draw conclusions on flawed information.

Ed, Ed...

 

I don't doubt any of what you are saying, and never did.  There is considerable amount of banter about SLI and I'm proposing it's not going to address this issue well.  Do you have an opinion ON THAT QUESTION ED?  Or do you just want to rant about how I don't get there are unoptimized add ons for P3D?  Everyone myself included knows this Ed.  I see the CPU boundedness at default high density airports too Ed--you know, the ones packed w/ the installer for P3D?  Forget it Ed...

Noel, out of curiosity, what are your Affinity Mask settings and have you enabled Hyper Threading?

 

Also have you experimented with the Fiber Frame TIme Fraction setting?

Ed, Ed...

 

I don't doubt any of what you are saying, and never did.  There is considerable amount of banter about SLI and I'm proposing it's not going to address this issue well.  Do you have an opinion ON THAT QUESTION ED?  Or do you just want to rant about how I don't get there are unoptimized add ons for P3D?  Everyone myself included knows this Ed.  I see the CPU boundedness at default high density airports too Ed--you know, the ones packed w/ the installer for P3D?  Forget it Ed...

I loaded into LAX and saw 30fps solid (even in motion and flying around LA), with cloud shadows and I'm running a GTX 660. Of course, I didn't load in any third party anything. Just Prepar3D 2.2. That's my point. I don't see where loading in anything for FSX is a valid starting point to deciding how the new sim's rendering engine performs or will perform.

 

I think to get optimal performance for aircraft in P3D v2... developers are going to have to change the way they code the complex systems.

 

I think to get optimal performance for scenery in P3D v2... developers are going to have to change the way they create their scenery. They're going to have to redo texturing, 3D object design... lots of things to bring their 3D models into a better performance range. Things that didn't matter one bit in FSX are absolutely critical in Prepar3D.

 

In the long run, I think it will work out... as P3D is at least an actively developed platform with a developer that wants to actively interact with both consumers and developers.

 

As for will SLI fix it... nope. But then I'm also one who points out that moving to 64-bit won't fix bad code either.

I understand the point that developers need to design add-ons specifically for Prepar3d v2.x to make them perform really well. However, there are also tons of add-ons out there (especially the Orbx stuff) which is labeled Prepar3d v2 compatible and I have the gut feeling that they are also just relabelled FSX stuff with some slight adjustments because tossing Orbx add-ons into the mix clearly makes the sim perform worse. And that's not only because the scenery gets more complex. Just installing FTX Global already introducing slight microstuttering compared to the default scenery. And there are so much people who really expect SLI to make things better even with these add-ons. To be honest: I have the strongest doubts that this will happen. From what I read first test of the experimental SLI support show improvements which from my point of view do not justify the investment. Coding add-ons specifically for Prepar3d v2 is the only way we will get the performs we all hope for. SLI with the current add-ons will just be a disappointment. However, I'm happy if people prove me wrong when the SLI support will be officially available in v2.3. I will definitely wait for some prove that performance really gets better with SLI before investing in a second GPU...

Until the claim is made that it's even possible to add significant optimization the question remains ultra relevant, especially with what you are saying.

 

I can assure (as in have discussed this with Wes B.) you there is A LOT of code being implemented to support existing 3rd party airport designers ... some of there processing is NOT good for how P3D DX11 operates (specifically how objects are being injected) and hence produces significant performance impact.  Many are still using older techniques from FS8.

 

I think we need to be patient and wait for products to come out that are designed exclusively for P3D V2.x.  Right now most airports are being designed for FSX first and foremost and then "compatibility" is added for P3D (if they intend to sell to the P3D market).  But key is "compatibility is added" ... these are not "from scratched design exclusively for P3D and DX11".

 

If you want very specific details.

 

1.  Object injection (used a lot with airports) doesn't get batched so lots of extra draw calls

2.  Extra surface tricks used to work around issues in FS9 and FSX (in other words extra draw calls objects no longer needed in P3D V2.2)

3.  No one is currently using texture compression formats specifically for DX11 HDR - these are BC6H and BC7 (see http://msdn.microsoft.com/en-us/library/windows/desktop/hh308955(v=vs.85).aspx)

 

I believe FSDT KIAH will be one of the first to really dive into support for P3D V2.x and they have indicated to me they'll be using at least those BC6H and BC7 texture formats ... which obviously means they'll have to different DDS files for FSX and P3D ... should be easy enough to verify

 

I can understand 3rd parties caution on doing textures and techniques exclusive to P3D ... they don't work in FSX which is still the current bread an butter market.  So they have to really make two separate products ... one for FSX and one for P3D -- that's expensive to do especially in such a relatively small market.

 

 

 

As for will SLI fix it... nope. But then I'm also one who points out that moving to 64-bit won't fix bad code either.

 

If done right quad-SLi will fix all    

 

True, 64bit doesn't fix bad code, but who are we to determine "bad code" ... is supporting legacy ways of doing add-ons considered "bad code"?  It's a double edged sword, removing "bad code" could break compatibility.  Optimization is always possible, but at some point us developers reach a point of diminishing returns, one can spend months and months (even years) on optimization ... there needs to be a balance between optimization and progress.  64bit is still very much on LM's plate and one hopes will give use a huge LOD radius similar to what can be achieved in XPlane.

 

You gotta admit, Xplane's level of detail in the distance is far better than what can be done in P3D -- how realistic that is isn't the debate, the fact it can be done because it's a 64bit platform (I very recently installed the SimHeaven stuff in XP10 after prompting from an XP10 fan and was up to 12GB memory usage).  This is just the reality of the differences in these two platforms ... I have them both and enjoy both for different reasons and they both require a blind eye.  

 

But I still want to see P3D be 64bit and I hope LM doesn't spend too much time on optimizations ... there is still some work to be done for sure in P3D ... such as terrain loading system (which I know they are working on) and managing threads.  But at some point LM will hit the wall of diminishing returns and will hopefully move forward with 64bit.

 

Cheers, Rob.

Oh, I agree that we need 64-bit... just don't agree that it solves everything. Bad code is still bad code... addons that chew up memory that it doesn't really need... is just bad.

 

I've found that programmers (in general) have gotten sloppy/lazy/unconcerned with resource usage in software of late. It's not just an issue for flight sims... it's a problem across the board with a ton of software.

 

I suspect a great deal of programmers today would find it impossible to work with a 64k stack limit... remember those days?? LOL

 

 

I've found that programmers (in general) have gotten sloppy/lazy/unconcerned with resource usage in software of late. It's not just an issue for flight sims... it's a problem across the board with a ton of software.

 

I don't doubt they exists, but I do doubt it's "the norm" especially given some of the programmers that worked on FSX/ESP (some were extremely talented people).  I have seen sloppy lazy code, I know it first hand as over the years I've inherited some ... and yes some of it is really bad, but I have to keep in context the issues around how the code was produced ... meaning, cheap export labor used and/or extremely short time frames to deliver.

 

Optimization can continue indefinitely, it's one of those programmer tasks that really has no "ending" -- what a PM or developer needs to do is find a balance so that progress is made in reasonable time frames.

 

But to call code "bad", I would need to see the code before passing judgement on it.

 

What I have seen are people suggesting code is bad because it doesn't run well with "their" hardware ... this to me seems more like an expectation with no solid technical foundation to back up the expectation.

 

Cheers, Rob.