Multithreading and 64bit

[damagefilter 34]

I get how cities require more draws and how that could reduce frame rate if the GPU bottle necked, but the GPU is not bottle necked in the video. The GPU usage actually drops which is the reverse of what I'd expect. Maybe it's just an inability on my part to understand but I feel that something else is going on here.

That very strange behaviour.

See, as I mentioned before, the draw call in itself, doesn't necessarily mean high load on your system.

What does produce the high load, as Lady Kyrah hinted, are the shaders that need processing and the triangles that need to be put together to something visible.

And that is a lot of stuff.

 

But clearly, as you can see, high load on your system, doesn't necessarily mean bad performance either.

Forest == (relatively)high load but still good FPS.

 

So, the next logical step would be to assume that it's not that it's bottlenecking anything. If it would, you'd see system load go nuts.

Which you probably don't.

That leads me to the conclusion that it simply can't go any faster.

 

There is a game, called KKND2 Krossfire.

That's an RTS and it's pretty old. It would run on a PC made of twigs.

It was designed so each player can have about 100 units on a map, give or take a bunch.

You can change that value to something far beyond the 100.

If you do that and then, ingame, actually build all the units (lets say 700 per player)

the CPU doesn't give a flying damn (nor does the GPU). But the game still starts to suffer from FPS drops.

Its algorithms are simply too slow to process all the unit data.

[KarmaCoin 72]

Slow algorithms shouldn't result in lower GPU and CPU usage. A slower algorithm just means it takes more clock cycles to complete the task which certainly leads to lower FPS but the CPU and GPU should still be getting fully utilized.

 

The reverse of CPU/GPU usage is CPU/GPU idle time, i.e the amount of time the processor wasn't executing anything (including the slow algorithm)

 

The frame rate drops in the video because the GPU usage drops. So the real question is what is causing the GPU to not be utilized. I'm going to try increasing the priority of DayZ while running it to see if that helps. If I get time after work I'll try throwing it into a debugger to look for sleep calls or other pitfalls which could result in the process yielding CPU time.

[Lady Kyrah 1110]

It seems to be a lot of triangles but performance shouldn't be bad there because of batching technique. This way single draw call can render a lot of instances of the same object. It may be confusing, because polycount of the scene stays the same but batching can save a lot of time between frames. Forests shouldn't EVER drop below 60fps with vsync on $300 cpu and gpu but it does.

DayZ SA looks decent today. It is huge open world, however today with occlusion culling, LoD and other tricks we can have almost infinite game world and keep great graphics. If anyone says "dayz has bad performance because the game world is big" remember that's bullshit - it's just not optimized well enough.

That's if they do batching. Occlusion culling is very delicate balancing act between what you can gain from the occlusion and what you lose testing for occlusion. By experience it just doesn't work properly when there is a lot of objects as potential occluders. DayZ (and the rv engine in general) could probably benefit from autobillboards but there might be technical reasons as to why they aren't doing it yet (air vehicles?).