But it get's more and more laborious if you wan't to use actual planes because nearly no one cares about backwards compatibility.
Since 2.10 frame rate also drops significant.
Thorsten wrote in Sun Jun 28, 2015 10:12 am:Since 2.10 frame rate also drops significant.
Actually no - this was the 2.0 scenery introduction point, and using the new scenery drags framerate. If you would run old scenery with the new binary and the same settings, it'd be really fast and efficient.
Thorsten wrote in Mon Jun 29, 2015 9:19 am:......FG is getting faster. There's plenty of optimization that's being done behind the scenes.
.........
Rebecca Palmer wrote:we appear to be single-thread-CPU bound (and if we are on my machine, we probably are on most)
Tim Moore wrote:The depth-pass-only pass is a well known optimization, but the fact it
is not helping implies that our bottleneck is not in fragment
processing. I've suspected for years that it lies on the CPU, and have
been trying to optimize our scene graph a bit...
Mathias Fröhlich wrote:It *is* on the cpu.
At least for most of the use cases. Every now and then there is an other limit
that comes up for specific stuff. But we are *mostly* draw limited. The draws
are way too small to be efficient.
James and I were talking about this some time ago.
Tim Moore wrote:we also have CPU bottlenecks upstream too.
Durk wrote:Tim and Mathias already said that we are CPU bound and I can confirm by experience.
Hooray wrote:Basically, your GPU is a massively parallel special-purpose cluster of "CPUs" (depending on the hardware, hundreds of tiny cores) that can do certain mathematical computations extremely well/fast by partioning the task at hand and handing each job to another work queue, which may be processed by hundreds of "dedicated cores sitting on the GPU" in parallel. Basically, your GPU is super computer (certainly when compared to the computing power of the 80s or 90s).
On the other hand, not all things can be easily run on a GPU (GPGPU aside for now) - and many parts of FG are simply not rendering-related, and cannot easily be moved to the GPU.
So your CPUs and idle cores are still relevant to handle all non-rendering related jobs, and other computations that are not appropriate for the GPU (ATM). Things like AI traffic, the FDM, autopilot computations, Nasal code - these all run in the main loop, before the final frame is created and rendered. So depending on how long each step takes, frame rate/spacing may fluctuate - which is less likely to show up on really fast systems like Thorsten reported.
Thus, the idea is not to use idle CPU cores for rendering related stuff - but rather optimize the FG<->OSG pipeline such that more main loop resources become available, so that certain tasks can be offloaded onto other cores. For example, OSG is able to run certain rendering-related optimizations asynchronously, outside the main loop. But that requires a paradigm change, because of the way FG makes currently use of OSG in a fairly sub-optimal fashion, even though Thorsten is right in saying that this particular issue doesn't show up on extremely fast systems with high-speed CPUs.
So Thorsten's system is unfortunately not representative of the overall situation for all users - because not everybody has a $ 3k workstation-style laptop at home with 8 64 bit cores (hyperthreading included), 16gb of RAM and a NVIDIA 670M 2gb SLI configuration. We need to be careful not to compare apples and oranges here, I have no doubt that Nasal code or poorly coded C++ code doesn't really show up on such a system.
Which doesn't really mean that anybody in particular would be wrong here, but originally the FG main loop was designed to be a single sequential loop that scaled roughly with the frequency of the CPU - which is why someone running FG on a "high-end" gaming computer today may very well have the impression that FG's architecture is not the problem, especially because of the number of background threads already added over time and now working behind the scenes, which ALREADY make use of additional cores to reduce the footprint of the main loop.
Again, performance issues like these are not obvious on high-end machines, no matter if it's framerate, frame spacing or the Nasal garbage collector - on a 3-4 ghz multicore system, there's usually enough horsepower available to make up for architectural shortcomings - but that only hides the real problem. And it's a well-known issue that computers used by developers are usually high-end machines, which end up masking problems encountered by end users, who may very well use much less powerful hardware.
If we all had access to 10ghz machines, we would all be having the impression that FG's architecture is rock-solid and that GPUs are the main problem
There's a reason why software companies tend to keep lots of hardware around, to do tests and benchmarks on old/common hardware.
Keep in mind that we still have many people here reporting that Rembrandt wouldn't work too well for them, which really isn't a totally different issue.
We have seen now several times how you, and others (myself included), have rejected bug reports from people with average hardware, just because certain issues (actual bugs) would not even show up on our radar, such as tons of RAM being leaked, or property callbacks/listeners being re-registered literally hundreds of times.
Users browsing this forum: No registered users and 2 guests