P3D multicore usage anomoly

[itsjase 52]

18 minutes ago, Noel said:

"All of you folks out there including SteveW and itsjase:  do you understand why something like this is out of the question?  Is tweaked ESP engine simply unable for technical reasons we don't appreciate?"   NO ONE answered this except SteveW gave an honest response which proves at least he understood the question and did not come back w/ the judgmental polarizing knee-jerk reaction you did.

Without going on a long winded explanation, it's a very difficult thing to do, and not worth the development time, when it only takes a few minutes to manually adjust settings.

There's plenty of information out there on why this is so difficult, if you want to google it.

More recently some engines have introduced dynamic settings for some settings such as resolution, but these are in an attempt to lower GPU usage, not CPU. In P3D it is usually the CPU usage that is the issue, and the settings that affect cpu usage are much harder to change "on-the-fly".

And for those that can be changed, there's already FFTF Dynamic as mentioned in previous posts.

Edited April 24, 2019 by itsjase

[Noel 4,486]

4 minutes ago, itsjase said:

Without going on a long winded explanation, it's a very difficult thing to do, and not worth the development time, when it only takes a few minutes to manually adjust settings.

Oh come on, humor us and go into that long winded explanation we're all ears to learn exactly why the ESP engine can't be modified to accommodate user-selected prioritization of CPU/GPU related demand.  And not worth the development time because it only takes a few minutes to stop and manually adjust settings?  That is the point now isn't it, to eliminate the need to disrupt the suspension of disbelief to do something manually so you can make it all the way to touchdown?

[SledDriver 39]

2 hours ago, itsjase said:

Without going on a long winded explanation, it's a very difficult thing to do, and not worth the development time, when it only takes a few minutes to manually adjust settings.

> not worth the development time

I can't accept that. That is just head-in-the-sand stuff.

So you are happy that you spend, and continue to spend, possibly thousands to get hardware on which you then run a sim which you have to tweak to far below its ability for 98% of your flight just so it continues to deliver good results for the other 2% of the flight?

And your accepted response to when you see something like a microstutter in a heavily loaded situation is to turn the entire sim down yet more for the entire flight.

Surely, for example, it would be better if the sim could do things like dynamically reducing the autogen/cloud draw distance as you approach a complex airport? And no, I'm not saying that is possible with present code...

[Luke 782]

4 hours ago, SledDriver said:

> not worth the development time

I can't accept that. That is just head-in-the-sand stuff.

So you are happy that you spend, and continue to spend, possibly thousands to get hardware on which you then run a sim which you have to tweak to far below its ability for 98% of your flight just so it continues to deliver good results for the other 2% of the flight?

Whether we are happy with it is not the point. It's obvious you aren't happy with it.

Every software development team has a pipeline of feature requests, prioritized based on customer demand (hint: neither of us are LM's target customers), ease of implementation and overall product benefit. Given what I've seen of commercial flight simulators, it is plausible that LM's other customers may place less importance on graphics quality and more on SimDirector or other features. They don't care about a few stutters compared to other features.

Cheers!

[Noel 4,486]

3 hours ago, Luke said:

Whether we are happy with it is not the point. It's obvious you aren't happy with it.

Every software development team has a pipeline of feature requests, prioritized based on customer demand (hint: neither of us are LM's target customers), ease of implementation and overall product benefit. Given what I've seen of commercial flight simulators, it is plausible that LM's other customers may place less importance on graphics quality and more on SimDirector or other features. They don't care about a few stutters compared to other features.

Cheers!

No one's 'happy' with the behavior we've been discussing here.  You may personally accept it and believe it's either not possible to address, or believe their commercial customers don't care about stutters which may or may not be the case--thanks for your opinion.   

I think it's plausible if someone is using their product primarily for SimDirector and then their flight lesson chokes upon entry into the big terminal they're going to just simply ignore this especially at what they probably have to pay for this commercial license?  Or maybe they're using stick figure graphics you're thinking so they're machines don't choke?  The proposed mission is to improve the experience for everyone, not just armchair pilots here.   

Maybe someone from LM will chime in here or over there and explain why it's so fundamentally prohibitive to do because of the engine's architecture, as in a complete re-write.  That's plausible, or not. Certainly no one here has yet given any plausible reason why the concept could not be implemented, and even for a very reasonable cost.

Hakuna Matata!

[Luke 782]

27 minutes ago, Noel said:

Maybe someone from LM will chime in here or over there and explain why it's so fundamentally prohibitive to do because of the engine's architecture, as in a complete re-write.  That's plausible, or not. Certainly no one here has yet given any plausible reason why the concept could not be implemented, and even for a very reasonable cost.

Believe it or not, I agree with you that it's likely not too complex, nor expensive - that's not my point. Like any other engineering team, I expect the P3D team has a list of prioritized features far in excess of their development/QA capacity. That means there are plenty of feasible features that aren't at the top of the priority list and aren't getting worked on now or in the next few releases.

Cheers!

[Noel 4,486]

21 minutes ago, Luke said:

Believe it or not, I agree with you that it's likely not too complex, nor expensive - that's not my point. Like any other engineering team, I expect the P3D team has a list of prioritized features far in excess of their development/QA capacity. That means there are plenty of feasible features that aren't at the top of the priority list and aren't getting worked on now or in the next few releases.

Cheers!

Or maybe they're methodology of evaluating the wants of their customers isn't perfect, and they're missing an opportunity to make the product noticeably better.  No one likes stuttering animation and this is a global issue in that it has the potential to affect a wide range of scenarios and is not just another 'feature'.  Whatever the real reason which could be many as to why we don't have this capability it ought to be prioritized.  The shear amount of time people spend fiddling with this stuff might be entertaining for some but I think collectively it's a lot of low-yield time.

Hakuna Matata!

[itsjase 52]

 

11 hours ago, Noel said:

Oh come on, humor us and go into that long winded explanation we're all ears to learn exactly why the ESP engine can't be modified to accommodate user-selected prioritization of CPU/GPU related demand.  And not worth the development time because it only takes a few minutes to stop and manually adjust settings?  That is the point now isn't it, to eliminate the need to disrupt the suspension of disbelief to do something manually so you can make it all the way to touchdown?

I feel like I'm beating a dead horse here, I don't think any explanation I give will satisfy you, so this will be my last response in this thread.

It's nothing to do with the ESP engine, it's to do with how real-time applications use the CPU and GPU in general. I know you want a simple explanation, but there isn't one. Without a deep knowledge of low-level engine programming it's very difficult to explain the whys and hows.

I've been trying to think of an analogy for it, but it's difficult. The best thing I've come up with is this. Think of a Pizza, and let the Pizza box be the sim. Cutting the pizza is done on the CPU, moving the slices off onto your plate is done on the GPU. To dynamically adjust GPU settings, all you have to do is move more or less slices onto your plate at a time, easy. To adjust CPU settings though, which is changing the number of slices, is not so easy. If you had 8 slices  to begin with then realise that's too many slices for the CPU to handle, and that 6 slices would be better, you need to either get a new pizza or un-cut it, before cutting it into 6 slices.

Unfortunately it's human nature to want to understand everything, and it's very hard to believe something you are told if it doesn't support your views or you don't understand it. This same phenomenon is why in this day and age we have flat-earth believers. The reality is we can't understand everything, if I read something posted by someone more knowledgeable in a certain area than myself, I'm inclined to believe it, even if I don't understand it.

[jabloomf1230 2,445]

42 minutes ago, Noel said:

Maybe someone from LM will chime in here or over there and explain why it's so fundamentally prohibitive to do because of the engine's architecture, as in a complete re-write.

I hope that you weren't really serious about that  and that's a rhetorical question.

LM staff have stated a bunch of times publicly that the flight sim community is a target audience, among others. It's certainly not their flagship market like the Pro Plus version and other specialized land-based combat derivatives (see the readily available official LM videos on the Internet with links that have posted a number of times on AVSim). But the hundreds of thousands of Academic and Pro seats that have been licensed provide LM with a test bed that is invaluable. They have also stated from time to time that their first priority is making the sim work correctly on a variety of hardware configurations without the added burden of using 3rd party add-ons. Now, if someone wants to make an argument that the stock version of P3d4 is not suitable for "real" flight simulation, that's their prerogative.

But for the most part, their development partner program generally ensures that the common add-ons do work without problems. The problems do become apparent when a whole bunch of add-ons are combined with demanding IQ settings. That problem is beyond LM's control. And because LM works closely with their partners, it's unlikely that the base sim would be upgraded in a fashion that would put partners out of business. I laugh at the never ending posts on the official P3d forums, where a user asks LM to "fix the ATC". There are what, 5 ATC add-ons that work with P3d4? And there's  almost as many weather injector add-ons. It's almost like some users don't realize that these add-ons exist.

But getting back the subject at hand, the only real solutions to performance issues in any flight simulator is to either buy new hardware or turn down the IQ settings (which includes those settings found in complex add-ons). I wish that this wasn't true, but it's been true for at least a decade. And it keeps getting worse as users clamor for more features, eye candy and realism.

[Noel 4,486]

10 hours ago, jabloomf1230 said:

But getting back the subject at hand, the only real solutions to performance issues in any flight simulator is to either buy new hardware or turn down the IQ settings.

That's your opinion which assumes everything possible has already been accomplished.  I don't believe it.  Here's an illustration of the problem we all have to one degree or another:  I have a 6 y/o GPU, a GTX Titan original.  I have terrain and cloud shadows, at the onset of my flight out of KCIC set to 30,000.  GPU utilization is a 58%.  I takeoff and fly towards SF.   Over many minutes of flight slowly but steadily GPU use starts creeping up, predictably, as I encounter more buildings and sloped terrain.  By the time I'm getting near Vacaville GPU use now is right at 87% and climbing, slowly & predictably.  I know where I'm headed, and even the sim does because I have entered a flight plan that my destination is KSFO.  What happens now is that the sim blindly attempts to continue delivering the shadow goods to me to the point stuttering begins to ensue.  So I stop, go to options, and reduce distance or remove shadows and all is well again.  Please elaborate on exactly why the sim engine can't begin to shorten shadow distance as GPU use approaches 90% or whatever I set in the dialogue that does not exist.

The same logic can be applied to more CPU-dependent features, for example LOD radius and AG/V density.  Right now those can't be changed in real time because the engine was presumably not designed to do this. Please elaborate on why a graphics engine can't be designed to do exactly what was described in the shadow distance example.  

Next, why do you believe LM decided to open their coveted commercial FS software to gamers, yes gamers and wannabe pilots?  Publicity?  Public relations?  Why?  Beta testers?  Philanthropy?  Not long ago I visited their home page and was delighted and amused to notice they actually acknowledged 'desktop flight simmers' (or equivalent) was part of their target audience.   It's gone now, but they do enjoy touting all of that high demand 3rd party content you correctly state stresses performance:

"Prepar3D furthers the development of Microsoft^® ESP^™ while maintaining compatibility with Microsoft Flight Simulator X, allowing many thousands of add-ons to be used within Prepar3D."

So far I have zero reason to assume a real-time modulation algorithm can't be developed that allows users to prioritizes what matters.  We've got some here claiming it's because it's impossible, some saying it's not a priority for LM, and others still saying it's doable but prohibitively expensive.   If LM wishes to use compatibility w/ thousands of add-ons as a purchasing incentive then yes they really should think about the concept of giving USER CONTROL in real time w/o the need to STOP and ADJUST.   That's so inelegant, so stupid.  Near as I can tell CPU performance improvement rates have slowed to a veritable crawl over the past many years, and yet content continues to be released that only stresses hardware more and more over time. 

I'd love to see the full gamut of licensees of P3D, and exactly how many of those as a percentage could give a rip about what we're talking about here.  I don't believe it's just a handful of isolated gamers, I believe more and more commercial users will care over time absolutely, and yet once again, the hardware improves very slowly relative to content, overall.  So unfortunately you can't overcome this with hardware.

Edited April 25, 2019 by Noel

[Noel 4,486]

11 hours ago, itsjase said:

The reality is we can't understand everything, if I read something posted by someone more knowledgeable in a certain area than myself, I'm inclined to believe it, even if I don't understand it.

I'm sorry, which is it again?  A real-time smart user-controlled algorithm is not possible?  Too expensive develop, no one cares?  

"It's nothing to do with the ESP engine, it's to do with how real-time applications use the CPU and GPU in general."   You're committing to the argument it's not possible.  OK great, now we know LM's priorities are not the issue, it's simply not possible, at least from one of our resident authority's perspective.  See if you can explain why in this example:  what is it that causes the user to want to stop and dial back GPU-related sliders?  If I don't have GPU-z running I don't really know when to stop, I depend on the appearance of stuttering which typically happens when in this example when GPU use starts getting close to 100%.  Now if I use GPU-z, I can easily see the slow and steady increase in GPU utilization, WELL BEFORE I get to the level of impacting video animation quality.   Ergo, GPU utilization is a predictor of ensuing poor video animation--we don't need to wait until stuttering commences, we stop the sim and move the sliders impacting GPU utilization back.  Now if we had to wait until stuttering happens, then sure it's too late and we have to bake a new pizza.   But, we can see what's coming down the flight plan can't we, and manually adjust.  I see no logical reason why the engine can't do what my intracranial CPU does all day everyday!

All I'm hearing here is the logical fallacy of appeal to authority, NO ONE, has explained HOW and WHY this is not possible.  Once again, the other 'authorities' here will tell you it's possible but no one cares, or it's too expensive.  Which is it again?  What a crock of BS!

Edited April 25, 2019 by Noel

[SteveW 1,792]

We are talking about a technology that, by its nature, is designed to extract what is feasible, and infeasible, at the leading edge of power availability.

The design goals so far have not been to intervene in the way ultra high definition is absorbed and any kind of dll code interjected with the simulator. Instead it is more leaning toward a kind of test rig where we get back what we put in and discover the limits for ourselves.

To play with limiting requires a more sophisticated backend to deliver part details as and when it is desired to maintain desired performance. Some of these techniques are already in place with tessellation and replication. The move to DX12 and Vulcan also improves in this area slightly to provide more granularity to pipelines.

So it is coming but we lead at the edge of power and prefer to push the boundary and leave limited fields of view to the consoles whereby they can look into a mist up the road to maintain performance.

Edited April 25, 2019 by SteveW

[SteveW 1,792]

So reading into that, it should be evident that current hardware has walked along a trail of performance improvements that are at the leading edge of consumer technology. These increases in capacity have not so much been increases of capability. The design of code supports the hardware technique.

As far as cost or complexity is concerned. I mean that these things are relative to current development techniques based on the available consumer hardware.

Given the time for a team to move onto goals of performance stability, that would become the norm and be no more complex or expensive as the norm is currently.

[Noel 4,486]

1 hour ago, SteveW said:

So it is coming but we lead at the edge of power and prefer to push the boundary...

So this argument seems to say, 'not in this domain at least at the present time, that is currently only in the domain of consoles', save a few other features like tessellation, etc..   Fair enough that is the current state of priorities.  What's especially relevant to WHEN this starts to be maximally prioritized is the fact processing power improves so modestly nowadays.  My trusty 3930K is still, 6y later in terms of what seems to matter most, that coveted single-thread performance, is a grand total of about 44% improved w/ a 9700K or similar.  Meanwhile, ORBX TrueEarth appears.   So what's hamstringing the approach we keep describing here?  User sets CPU/GPU thresholds, engine adjusts according to that plus considers what's coming down the flight plan in the next few seconds.

[Bert Pieke 7,584]

On 4/23/2019 at 11:52 PM, Bert Pieke said:

 

I just installed FFTF Dynamic and it works just fine on P3D V4.5.