[roeter]

Thanks for the tip wrt the "Z" tools - didn't know of these (never worked with real time stuff).

This immediately showed what happened : the culprit is the CPU, and it is a bit of a nasty trick.
The nominal frequency for the CPU is 2.3 GHz, but it has a turbo mode of 3.3 GHz.
When settings are that max. allowed load is 100%, the CPU will switch to turbo. But apparantly it can't keep up turbo mode continuously - whether it just can't or whether it's temperature related I don't know. But what happens is that the CPU keeps slipping out of turbo mode - which means it slips back from 3.3 GHz to 2.3 GHz, but often it slipped further back - to 1.7 or even 1.1 GHz. That's obviously a quite noticable slip.
What I have now done is set max. allowed CPU load to 95% - this keeps it out of turbo mode and at an almost constant 2.3 GHz. As a result, the maximum FPS obviously is lower, but - and that's much more important - it is now very stable. There were still some CPU frequency slips, but much shorter and far less frequent than when on turbo.

What did surprise me a little was the GPU load was only just over 50%. Also, 4 out of the 8 CPU cores were completely idle, 3 were at somewhere between 30% and 50% and only one was at 100%. Apparantly, that is the FPS bottleneck. Makes you wonder if splitting the process into more threads would do any good here - if possible, of course.

Thanks for your help,
Rob Roeterdink

[James Ross]

 roeter, on 04 April 2014 - 09:28 AM, said:

When settings are that max. allowed load is 100%, the CPU will switch to turbo. But apparantly it can't keep up turbo mode continuously - whether it just can't or whether it's temperature related I don't know. But what happens is that the CPU keeps slipping out of turbo mode - which means it slips back from 3.3 GHz to 2.3 GHz, but often it slipped further back - to 1.7 or even 1.1 GHz. That's obviously a quite noticable slip.

Yeah, that's going to tank performance. I'm happy it's been identified, although the fix sounds like it isn't completely ideal either.

 roeter, on 04 April 2014 - 09:28 AM, said:

What did surprise me a little was the GPU load was only just over 50%. Also, 4 out of the 8 CPU cores were completely idle, 3 were at somewhere between 30% and 50% and only one was at 100%. Apparantly, that is the FPS bottleneck. Makes you wonder if splitting the process into more threads would do any good here - if possible, of course.

It obviously depends on CPU and GPU, but yeah, we are usually limited by the Render Process' CPU time. Typically I'll see 90+% render, about 25% updater and almost nothing in sound (loader is obviously in bursts of 100%), though Mid East Plus is a notable exception where the updater gets a good run for its money, often topping out the 90+% range too.

Unfortunately, most of what can be split out from render has already been done (to updater, sound and loader). The bottleneck is effectively the sheer number of draw (and other GPU API) calls, all of which incur a relatively high overhead. There will be some extra overhead due to .NET but this exact thing is such a problem Microsoft's recently announced DirectX 12 is all about fixing it. :bigboss:

For our part, we are doing what we can to reduce draw calls. I recently discovered (and this will be the first time I've mentioned it here) that DirectX 9 (and GPUs without tessellation engines) actually support real instancing of models. I hacked up a version of OR with this and got a scene with 12,000 draws down to 8,000 though it didn't have quite as much impact on FPS as you'd naively expect (more work for me to figure out the best way to utilise this).

There's always more work we can do, but when the limiting factor is other people's code (GPU and OS drivers) we can only do so much.

[rdamurphy]

Intel CPU's in the i-series, Sandy Bridge, Ivy Bridge, and Haswell, are designed to throttle down when they overheat. I'm using an aftermarket cooling fan, and EVO212, which probably explains why I didn't see the drop.

One of the main problems with GPU's is simply the x16 bottleneck, there simply isn't enough memory bandwidth with some motherboard/chipset/cpu combinations. And, in the case of Radeon chips, incredibly poor driver support. Sometimes the problem is lack of bandwidth between the GPU and onboard VRAM on the card itself, oddly enough...

I'm glad that CPU-Z and GPU-Z helped discover the problem, they're some very good utilities for freeware!

I've often run them while writing code and debugging OR in Visual Studio, it helped me avoid a major issue with the water, that caused framerates to drop into the single digits.

I'd also recommend MEMTest, If you ever have RAM problems.

Robert

[dennisat]

 James Ross, on 04 April 2014 - 10:55 AM, said:

It obviously depends on CPU and GPU, but yeah, we are usually limited by the Render Process' CPU time. Typically I'll see 90+% render, about 25% updater and almost nothing in sound (loader is obviously in bursts of 100%), though Mid East Plus is a notable exception where the updater gets a good run for its money, often topping out the 90+% range too.

This happens with Dorset Coast as well on complex activities. With Render and Updater close to 100% the sim gets very jerky at times.

Dennis