Very hot

[eLPuSHeR]

I am wondering how your monitor refresh rates are set? And most importantly, whether you are using VSYNC/Triple buffer or not.

I have noticed weird performance on some games (not LoG2) when my monitor is operating at 60 Hz instead of the current 75Hz, probably due to VSYNC being not properly implemented in nVidia driver.

For those of you who are having performance issues/FPS drops. What are your monitor refresh rates? Using VSYNC?

As I have stated somewhere else on this forum. I usually run with Video Write Combining DISABLED (USWC). It's enabled by default on Vista upwards and it cannot be easily disabled like it was under WinXP. Having USWC makes video output a little faster but I think it could introduce some minor lag resulting in small noticeable choppiness. Wagnard (DDU author) made me on request a tiny util to disable/enable USWC. If anyone if interested to check, just say and I will post the download link.

On another technical note. I have Windows 7 Superfetch disabled too. It shouldn't matter too much performance wise, but it could be a nice idea to disable it too just to pinpoint other probable issues while gaming.

[badhabit]

@Petri; "Playable" is a poor term for a game. Technically the game is playable at 10 to 15 FPS,

One remark here, while I personally played for instance quake 1 completely with 12-15 fps; I was taught by Log1 that trying this with this engine is not a good idea as the timed puzzles get additionally hard (up to impossible) by the extra latency... I guess you need at least 40fps. (I guess this is still true for Log2)

but that isn't what most people think of when they mean "Playable". Unfortunately, the norm these days is to push 1080p and 60 FPS, and anything less, it is seen as sub-par quality. Most players who spend the money on a current generation rig (so $1500 to $2500) are expecting to get solid 60 FPS in any game that comes out except for maybe something produced by CryTek. If they get less than 60FPS it is not acceptable. Since LoG2 doesn't seem to be a powerhouse, people expect solid 60+ FPS in the game. If this game was built by CryTek and utilized CryEngine 4, I doubt people would expect to see a solid 60 FPS on max everything. Most players assume that this game should run at a solid 60 FPS at all times with max settings, when they can play other games at 60 FPS, max everything, and when they don't there is a problem, and hence why we are having this discussion in the first place.

I agree, people expect when their rigs fullfill the recommended specification, in a reasonable resolution and with "standard" GFX settings, everywhere 60 fps.

But there is a second problem: people also expect PC games to scale to the hardware pretty well. E.g. that lowering the resolution or GFX options by on step is enough to achieve enough frames with slower hardware, and that setting everything to low will result in flood of FPS even with the flimsiest hardware. Here acts Log2 very PC untypical and unexpected, I have to say it is the worst scaling engine I have ever played, the FPS are only weakly linked to the resolution and the same is true for the GFX options.

Maybe Petri explained the reason for this paradoxical behaviour already, the enourmous number of DX calls per frame (6,000??!-> 360,000 per second? why we need so many world updates?). Many small calls will introduce an enourmous overhead, which is also a fixed overhead I guess, independent to pixel resolution and selected GFX options, which explains the weak influence of resolution and GFX options.

Also, why is it that you can only have a single thread to the GPU? Doesn't most GPUs have multiple cores, or is it because there is only a single physical route (ie the BUS) from the CPU to GPU? Is there any ways you could reduce the number calls by say, staggering calls so that different calls occur on different frames or cycles?

Yes, I have the feeling too (but without knowing here details, never programmed directX) that a queue (own thread) or/and joining calls to reduce the call number might be the thing to release the performance knot of log, finally.

[Dr.Disaster]

But there is a second problem: people also expect PC games to scale to the hardware pretty well. E.g. that lowering the resolution or GFX options by on step is enough to achieve enough frames with slower hardware, and that setting everything to low will result in flood of FPS even with the flimsiest hardware. Here acts Log2 very PC untypical and unexpected, I have to say it is the worst scaling engine I have ever played, the FPS are only weakly linked to the resolution and the same is true for the GFX options.

Maybe Petri explained the reason for this paradoxical behaviour already, the enourmous number of DX calls per frame (6,000??!-> 360,000 per second? why we need so many world updates?). Many small calls will introduce an enourmous overhead, which is also a fixed overhead I guess, independent to pixel resolution and selected GFX options, which explains the weak influence of resolution and GFX options.

Also, why is it that you can only have a single thread to the GPU? Doesn't most GPUs have multiple cores, or is it because there is only a single physical route (ie the BUS) from the CPU to GPU? Is there any ways you could reduce the number calls by say, staggering calls so that different calls occur on different frames or cycles?

Yes, I have the feeling too (but without knowing here details, never programmed directX) that a queue (own thread) or/and joining calls to reduce the call number might be the thing to release the performance knot of log, finally.

Actually petri already explained all this to you:

1) "We can push about 4000 calls per frame before the frame rate drops below 60." - petri
Means: resolution does not matter because it does not change the number of draw calls the engine has to send to the GPU.

2) "Using DirectX and OpenGL drawing commands have to be submitted in a single thread" - petri
Now this might be not that strict in more current implementations i.e. DX11 or upcoming DX12 but since you displayed that you value compatibility over performance AH is stuck with DX9.

I see only one ways out of this: the engine has to issue less draw calls so even low- to mid-range CPU's can achive a better framerate. This would require a line-of-sight check to determine if a to-be-send draw call would actually result in something outside of the players line of sight.

[badhabit]

Maybe Petri explained the reason for this paradoxical behaviour already, the enourmous number of DX calls per frame (6,000??!-> 360,000 per second? why we need so many world updates?). Many small calls will introduce an enourmous overhead, which is also a fixed overhead I guess, independent to pixel resolution and selected GFX options, which explains the weak influence of resolution and GFX options.

Actually petri already explained all this to you:

1) "We can push about 4000 calls per frame before the frame rate drops below 60." - petri
Means: resolution does not matter because it does not change the number of draw calls the engine has to send to the GPU.

Thanks for repeating my interpretation, appreciated. ;P
But, this not explains why he is doing this overall...

2) "Using DirectX and OpenGL drawing commands have to be submitted in a single thread" - petri
Now this might be not that strict in more current implementations i.e. DX11 or upcoming DX12 but since you displayed that you value compatibility over performance AH is stuck with DX9.

DX9 is not the problem. Switching to DX11 because the overhead is smaller there would be only workaround for the problem that in the first place too many calls happen.

[Dr.Disaster]

DX9 is not the problem. Switching to DX11 because the overhead is smaller there would be only workaround for the problem that in the first place too many calls happen.

DX11 allows multithreaded draw call submission. DX9 does not.
Now if the video driver can handle this is a different story but it would take away the single thread CPU limit we currently see with DX9.

[badhabit]

DX9 is not the problem. Switching to DX11 because the overhead is smaller there would be only workaround for the problem that in the first place too many calls happen.

DX11 allows multithreaded draw call submission. DX9 does not.
Now if the video driver can handle this is a different story but it would take away the single thread CPU limit we currently see with DX9.

Multithreading comes not by just exchanging a DX9 call against a DX11 call... the architecture needs to be changed.

But, I read a little bit... a DX call bottleneck is indeed a known problem (was discussed in a PC/console comparison and also here), as part-solution, also available for d3d9, is grouping of calls so called instancing (beside, in the last reference they were not impressed with mutlithreaded DX calls, max. factor 2 faster). Efficiently Drawing Multiple Instances of Geometry (Direct3D 9) GPU Gems2 - Chapter 3. Inside Geometry Instancing (irconically, here they specifically mention trees... sounds like Twigroot Forest performance drop) Maybe Petri is already doing this? If not, I sounds worth to be considered for implementation, looks like just an adaption of existing calls is required.

[eLPuSHeR]

I think the issue stems from the known fact Direct-X (D3D) being utter crap. Too bad MS just killed OpenGL in favour of its crappy graphical API. I am pretty sure if LoG2 would have an OpenGL implementation, it would run faster. Or a mantle implementation (sarcasm mode on).

We must also take into account that newer graphic cards drivers are going down the hill lately.

[Dr.Disaster]

Maybe, if petri can convince LoG2 to do something like "The Road to One Million Draws". Pretty much what i suggested further up by building more complex draw calls to reduce their number.

[eLPuSHeR]

Interesting read, even if I am not a programmer.

[badhabit]

Maybe, if petri can convince LoG2 to do something like "The Road to One Million Draws". Pretty much what i suggested further up by building more complex draw calls to reduce their number.

indeed, a good find, thanks.

@petri: I'm in a new area, as you asked for FPS for my "in-between min. to rec. system" here some results
Swamp area 1366x786 all high, GPU bound


Swamp area 1366x786 all low, CPU bound