Some of my FPS game users get “freeze hiccups” - game freezes for a short moment once in a short while.
For some users the freezes can last few seconds.
Some users reported it can be caused just by rotating the camera.
I can’t reproduce the problem on my machine, thus can’t debug it.
Anyone knows what could possible cause such problem?
Many times I noticed this when a new object showed on the screen, never shown before (I think resources is sending to GPU in this moment)
It happens constantly, not just on first appearance of things.
You’re right that first loading an object’s resources can cause a freeze, but that’s not the case.
Maybe it is environment issue?
Does lag appear if Urho is single-threaded?
I got a tester to run the game with -nothreads and it seems to solve the problem.
So there’s a problem with Urho’s threading?
I got a tester to run a performance profiler and here are some functions that came up:
I don’t know if these functions are relevant since it depends on how much time the tester’s app spent being frozen while he profiled.
I don’t think that Urho itself has some code or design problem with threading.
I’d blame tester’s environment: OS, CPU, background tasks that consume CPU.
I don’t trust occlusion very much, also. Try to disable it instead of threads.
Blaming the user’s hardware while any other game runs fine on it is quite biased.
I tried setting the occlusion triangle count to 0, but it didn’t solve it.
Occlusion culling is very important for performance in my game.
This may not be related to the issue, but out of curiosity, what compiler are you using to distribute your builds? Also, in the CMake settings, I’ve noticed that I’ve had to set the option below to generic for it to run on other PCs. I compile using MingGW for my builds.
// Specify the minimum CPU type on which the target binaries are
// to be deployed (Linux, MinGW, and non-Xcode OSX native build
// only), see GCC/Clang’s -march option for possible values; Use
// ‘generic’ for targeting a wide range of generic processors
URHO3D_DEPLOYMENT_TARGET:STRING=generic
I don’t see URHO3D_DEPLOYMENT_TARGET option available, documentation says it isn’t for Windows.
Ah, you’re right. I compile on Windows, but I use CLion + MingW, so it was available to me.
Made some progress. It isn’t related to threading, had two testers had different issues.
The big freezes are related to this:
I haven’t looked into it yet, but I asked one of the testers and he said it didn’t happen before. Could it be regression bug with the recent monitor number/refresh rate features?
Running sample 04 with -deferred also allocates and removes the same screen buffers several times:
https://pastebin.com/URHmY90Q
I think there’s also a bug that the new graphics::monitor_ never initialized or assigned by Urho. You can see its value in the log is -842150451.
This is disconcerting. I’d like this verified as a bug or not before 1.7 release.
The screen allocation seems to be an effect, not a cause. Screen buffers have a time limit before they’re removed.
I got a user with severe freezes (up to few seconds, previous one had few 100’s of ms) to send me a Very Sleepy report:
Got a WPA record from a user that has long pauses (this one is a second long).
services.exe? Thread starting?
In the end it turns out users were running out of GPU RAM.
Is there a way to see the GPU ram usage in Urho3D?
If you view Urho3D’s built-in profiler you have Resource type usage.
It doesn’t explicitly say how much GPU ram is being used, AFAIK memory usage in it is a mix of both GPU and CPU, but you’ll get a general idea.
Perhaps external tools can be used to check GPU ram usage.
Process Explorer is a general purpose tool that I use that also comes with some per-process or global GPU monitoring features. 