Grimrock

oh boy ...

Run on a single core the game maxes it out right at the starting spot in the cage with my fps being 45 and GPU load being 50%. By adding more cores (doesn't matter if 1, 2 or all) the load fans out into up to 4 cores (when allowed that many) with none maxed out, fps go up to 79 (with vsync off) and GPU load being 75%. (1920x1080, all settings High)

Dr.Disaster wrote:oh boy ...

Run on a single core the game maxes it out right at the starting spot in the cage with my fps being 45 and GPU load being 50%. By adding more cores (doesn't matter if 1, 2 or all) the load fans out into up to 4 cores (when allowed that many) with none maxed out, fps go up to 79 (with vsync off) and GPU load being 75%. (1920x1080, all settings High)

No screenshots as proof... but let's assume you did it right: where is your problem here seeing this situation as CPU bound (GPU load always significant <100%)? While not all CPU ressources are used (CPU load significant <100%, while not hitting the frame rate limit of 120fps)? And where is your problem in understanding that "no gain in FPS from 2 to many cores" in a CPU bound situation means no-multicore engine?

badhabit wrote:And where is your problem in understanding that "no gain in FPS from 2 to many cores" in a CPU bound situation means no-multicore engine?

Your assumption is: the more CPU's added the more FPS gained.

Yet the GPU is only one device and feeding one device from multiple sources at once always results in chaos. When 2 cores are able to do all the gfx work a program asked them to do you get a result. You can then spread the same workload out over 100 cores if you like but the result remains the same.

Dr.Disaster wrote:

badhabit wrote:And where is your problem in understanding that "no gain in FPS from 2 to many cores" in a CPU bound situation means no-multicore engine?

Your assumption is: the more CPU's added the more FPS gained.

Yet the GPU is only one device and feeding one device from multiple sources at once always results in chaos. When 2 cores are able to do all the gfx work a program asked them to do you get a result. You can then spread the same workload out over 100 cores if you like but the result remains the same.

OK, now we make some progress. Indeed, a real multicore engine would lead (inside Amdahl's law) to a speed-up approx. proportional to the cores. In reality, partioning of problems in paralizable chunks is a problem, which is one of the reason why still most software is effectively single core. You argue now similar, paralleization of the "GPU feed" will lead "to chaos", with that accepting that parallelization is hard. Your second sentence imply different things: either a fixed workload or limited bandwidth to GPU. First case is not the case as this would lead to GPU boundness. Second case is also not correct as we see in your other GPU-Z screenshot that bandwidth is not fully utilized while not achieving the aimed for 60FPS. Also, my tests with just increased CPU clock indicate also not a transfer bottleneck, as only the CPU clock gets faster not the bus or memory.

So, the conclusion stands, the grimrock engine can be CPU bound (not bandwidth), and throws out then more FPS with more CPU clocks but not with more cores (no multicore engine). So the recommendation for quad core systems is misleading.

@Dr. Disaster;

If neither your CPU or GPU is being maxxed out AND you still encounter lowered framerates, then what do you think the problem is? Why can't the problem be the engine itself? Since your computer far exceeds recommended specs and yet still suffers a framerate drop, and its not a hardware problem for you, then that implies its a software problem; hence its the Engine's fault. If its not a hardware issue, and there still is an issue, then its a software issue. And the engine is a software issue.

Also, do remember that Grimrock 2 is a 32-bit program, which likely means at most it supports dual core (I have not encountered any 32 bit games that support more than two cores; don't even think Crysis 1 did that), and has a hard cap of 3.1 (or is it 3.2) GB of RAM.

Palandus wrote:Since your computer far exceeds recommended specs and yet still suffers a framerate drop, and its not a hardware problem for you, then that implies its a software problem; hence its the Engine's fault.

or a driver issue

Palandus wrote:If neither your CPU or GPU is being maxxed out AND you still encounter lowered framerates, then what do you think the problem is? Why can't the problem be the engine itself?

If it would happen in general like anywhere i go in outside maps i'd prolly blame the engine too. Yet that's not the case. It's a rather trackable behavior that occures when lots and lots of stuff - and i really mean LOTS! - are together in the field of view and a simple turn by either "Q" or "E" can remove it entirely. This makes it pretty tough to isolate the real fps hog and that's what i am interested in like during the beta. We know that a lot of light sources can cause slowdowns like 10+ torches in a tiny room but in outside maps there is basically only one light source.