I think we’ll have the Garmin in at full res for the 172, baron and kingair by the end of beta.

I have wondered about this myself for IFR work. I would love to see a solid overcast layer that extends to the horizon (not limited by cloud draw distance). SkyMaxx Pro kind of has this option, but you must choose the lowest quality overcast setting to get it. Would be cool if you could combine good quality 3D clouds near the aircraft with a solid layer that extends farther out (perhaps this layer could be just a 2D texture blanket you see when above or below it).

No that’s pretty accurate – you can almost always use “more GPU” up by having a mix of bigger screen and more anti-aliasing. Since users sometimes like to run with crazy screens (3x 1440p x 16x FSAA) you can use a big GPU. Of course if you don’t have a huge screen, you might not need it.

For CPU, once you get 4-8 cores, more cores doesn’t help. And generally pure throughput is more important than more cores.

The problem is that our amount of multi-core usage depends a lot on what you do. Fly with AI? More cores. Fly with VATSIM – don’t need ’em. Fly with a lot of autogen and wxr? More cores. Fly without ’em….don’t need ’em.

I think of the i5 and i7 as good target CPUs, e.g. we should run well with 4 cores, and we should ideally take advantage of 8 virtual cores. So to the extent that we could push the cores on an i5 harder, I would like to get the rendering engine to scale a bit more. But to me dual-socket designs (which get you to the 12-16 virtual core count) aren’t target – there’s a big jump in hw prices to get that stuff, so if we saturated an i7 but dual Xeons were bored, I wouldn’t be looking to improve core use as my primary way to improve fps.

So what are your IDEALS? 😉

There is no ideal machine for everyone. It all depends on what you expect from your simulator (systems simulation, VFR flights with tons of objects and orthos, multi-screen setup with extreme resolution etc). Your machine is quite performant with a slightly outdated GPU. A better one would enable you increase certain rendering settings and thus improve graphics. Which one you should get depends entirely on your budget. More GPU Power gives you more eye candy – to a certain point from where you get into CPU limitation again. To confuse you even more it should be mentioned that some rendering settings are more CPU dependent (i.e. objects), some more GPU (FSAA) and some depend on both. Ben wrote a lot about this in his posts and there´s tons of information on this topic in the forums.

But to cut it short: A better GPU like a GTX770 would certainly enable you to increase settings like texture quality, FSAA, global lighting etc. Overclocking your i7 will also directly increase performance and is very easy these days.
If I´m wrong with anything technical, please correct me Ben 😉

There is still optimization to be had, including, possibly finding ways to use multiple cores to improve CPU render time. (Fixing CPU use on render is not easy because it’s not a naively parallel problem – the “easy parallelism” tasks have been on the GPU since the Geforce 256 over a decade ago.)

But one of the first remaining frame-rate optimization I’m going for on the CPU won’t be to use more cores – just to make the engine more efficient by using constant buffers. We won’t get there in 1030 (but we made some progress toward it in 1030) but we may get there within the v10 run.

I think I’ve mentioned this before, but I think changes to scattering are going to be pushed out to a later patch – they’re not done yet.

Patrick,

A thing must always be kept in mind, that is, not any software can be optimized to efficiently run on an arbitrarily large number of cores. Parallelizing the execution of a task does not come for free, it is often impractical and sometimes totally impossible, depending on what you want to do.

A piece of code can be spawn among several independent threads as long as the task assigned to each thread does not depend on the result of tasks assigned to other threads. If this rule is broken, then you get dependencies, that is, some cores must often interrupt their work while waiting for other cores to complete their duties.

Unfortunately, the kinds of tasks that are (almost) dependency-free are not that many (audio/video coding and databases, just to mention two examples); in the vast majority of cases, some specific parts of the work an application does can be parallelized, while the others are affected by dependencies and therefore will never be multicore-friendly.

To my knowledge, X-Plane has been enhanced to take advantage of multithreading for a while now, so I can suppose that if there was still room for big improvements without disrupting the current code base, Ben & Co. would have already put their hands on it and optimized it. So, either there are still big potential improvements but at the cost of a large overhaul of the current code, or the parallelizable parts have already been parallelized and further improvements, if any, would be marginal.

If I understood well the current status of the evolution of X-Plane, rather than spending further efforts in trying to multi-thread other parts of the code, LR found better potential improvements in optimizing the usage of the graphics hardware through improvements in how OpenGL is used. Am I right?

Regards,
Filippo