Page 10 of 16
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 11:29 am
by dahauns
eispfogel wrote:
But doing a demo and then a game are 2 different kind of shoes. I remember the group Farbrausch which did awesome demos(especially the 64k ones - the produkkt anyone?) and they also did games, but they really where bad and i don't know if this was because they did a license job for RTL or if something else was going on, maybe if they had a free hand, something like "kkrieger" would have turned out to be a great procedural generated shooter/engine.
Hey, the RTL Ski Jumping games were actually surprisingly fun!
But back on track - I'm actually surprised how well the game runs on my Dell Venue 8 Pro. Sure, everything on low (and I think it's time to invest into the gestureworks tool), but the FPS are better than expected.
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 5:08 pm
by vlzvl
First on is especially unfortunate, as multicore systems are standard and Grimrock is incapable of utilizing even two cores while starving CPU ressource wise.
Indeed, GR2 doesn't utilize more than 1 core. I started the game and manually changed the cores to 1, 2 and all (default),
not a single difference.
A good idea for @Petri is to add some (p)thread programming here and there, 2-cores might not satisfy users with monster rigs but they will certainly help low-ones where the cpu/gpu (?which one) pressure is just unbearable.
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 5:37 pm
by Dr.Disaster
vlzvl wrote:Indeed, GR2 doesn't utilize more than 1 core.
Actually it does use up to 4 cores. Yet they are not used at an even rate.
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 5:45 pm
by vlzvl
Dr.Disaster wrote:vlzvl wrote:Indeed, GR2 doesn't utilize more than 1 core.
Actually it does use up to 4 cores. Yet they are not used at an even rate.
I'm curius, how did you find that GR2 uses all cores?
Even if it uses them it's some kind of OS handling (as always), giving threads here and there but it's not something GR2 is programmed to, since there is 0% improvement (at least to me).
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 6:13 pm
by Dr.Disaster
vlzvl wrote:I'm curius, how did you find that GR2 uses all cores?
All cores? I wish it would do that
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 6:39 pm
by vlzvl
Dr.Disaster wrote:vlzvl wrote:I'm curius, how did you find that GR2 uses all cores?
All cores? I wish it would do that
actually it seems Grimrock 2 under-utilizes the CPU(s); Most of the overhead seems to be GPU stuff.
It's really difficult to measure how many cores a process is using.
I just did a test with some (custom) OpenGL application in my system which doesn't use
pthreads or any multi-threading library, just flat OpenGLs calls and indeed is using all cores, although this is a
OS selecting a core mechanism.
One needs to find
how many threads a process is using to calculate that.
I'm going to play with it a bit...
conclusion: GPU
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 7:09 pm
by Batty
I'm on Sleet Island with all settings on max 1920x1200 res.
My System
AMD Phenom II 1100T 6 Core
8 GB RAM
GeForce GT 630 1 GB (under recommended spec)
My CPU is happy but the GPU is getting crushed. No significant slowdown indoors but outdoors does slowdown somewhat but not enough that I've lowered the settings. Considering my video card is under spec and I'm on max settings, that's not bad IMHO.
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 7:12 pm
by hansmuff
Of course I have no knowledge of LoG2's implementation or the details of how it works but my guess is that the graphics engine needs a decent amount of CPU cycles, and perhaps the CPU code for that is not easy to multi-thread.
That could be because of calculations depending on the results of previous calculations, so they cannot be done in parallel. For instance if you tell Peter to pick an apple, and tell Paul to take whatever apples Peter has and then pick one himself.
If you did that in parallel, both end up with one apple because Peter hasn't picked the apple yet when Paul takes however many apples Peter has.
Doing it sequentially, Paul would have two apples since his turn takes place after Peter picked an apple.
It would help explain why I see one CPU core pegged 100% at low resolutions (more frames drawn, more calculations done on the CPU, fps limited by CPU), and not completely pegged at high resolution/detail (less frames drawn because of the GPU, so the CPU doesn't bottleneck as badly, fps limited by GPU.)
Now sure, I saw the cry for more customizations (no water reflections for instance) but it is absolutely not clear that it would solve that particular issue. Just like the available options only provide so much relief for lower-end systems, turning off water reflections may be similarly not giving much gain.
Again, all speculation, but offloading calculations to parallel threads is not always possible, or require so many changes to the engine that it isn't practical or reasonable to do. And I hate to sound like that guy, but that is where the minimum requirements come in. Expectations to be able to run with less than minimum are unreasonable, that's why there is a published minimum and going below is a risk that in this case wasn't well calculated.
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 7:19 pm
by Dr.Disaster
Batty wrote:GeForce GT 630 1 GB (under recommended spec)
Nah not really under. It pretty much hits the min req from a performance point of view.
Re: LoG 2 very poor performance...
Posted: Thu Oct 23, 2014 8:04 pm
by vlzvl
Again, all speculation, but offloading calculations to parallel threads is not always possible, or require so many changes to the engine that it isn't practical or reasonable to do.
Indeed, multi-threading is double-edged but results can be quite surprising.
The good with multi-threading is that your app
has access to the same resources.
But the bad with multi-threading is that your app
has access to the same resources.
I'm not asking for GR2 to get that kind of mechanism, i just followed the above screenshots.
..which screenshots shows that CPUs (and multi-threading) is not really the problem but graphic processing.
..which specific graphic settings can relieve lots of GPUs out there. For example:
Water reflections (that was just an example, but
low settings seems not affecting it)
LOD
Draw distance
Low version of object at distance (since Grimrock 2 is open world)
These things are easy to implement and far easier than MT coding