Windows 10 64 Bit VS Ubuntu 22.04 64 Bit GPU performance lag/issue in compiled game.

[MarkoKrsic]

Godot version

3.5.1 stable

System information

Windows 10/Xubuntu 22.04 (64Bit), Intel HD 530,GLES3

Issue description

In my game, Plethora of Bullets, a 3D FPS, I am experiencing serious perfomance issues in Windows. I have had a few players test it and they are getting better playability in Linux on an intergrated GPU than on Windows with dedicated GPUs. I am getting similar results with my testing. I have profiled the game, and can't seem to get a reading that would point to the bottleneck on Windows. In Windows a user tested it on a 2060 and was averaging 140+FPS but would still experience the 20-30FPS drops during the problem moments.

I have narrowed it down to a moment in the initial shot firing in the game and the initial rayscan strikes that launch a series of animations/particles. This leads me to believe there is a bug in the way something is being executed in the Windows build or pushed to the Windows drivers for OpenGL/GLES3.

There is a 20-30+FPS frame drop for me on my only available test machine at the moment from 30FPS to 1FPS for 2-3 seconds in the Windows build. In Linux with or without the compositor on, whether loading from SSD or HDD the game stutters for a few frames then breezes right through the animation load.

On second go around of play, when the player experiences a game over or when they manually reset the game to the start menu (leaving loaded textures/animations in memory?) there isn't any noticable lag in either Windows or Linux.

I am using the ResourcePreloader to load the animations, sprites,particles etc and have optimized the game to be able to hit an average of 35FPS@720P on an Intel HD530 running with a i7 6700 with 16GB RAM.

Steps to reproduce

Load the game, start playing, experience the lag upon firing the gun. Not sure how to include a reproduction code sample without including the whole game, 2.6GB build folder. Game is available to download on itch.io as a ~230MB executable for both Windows and Linux to compare the issue in play. I can provide the code that executes at the exact moment but am not sure how much use it would be without the specific meshes, textures and sprites in use.

Minimal reproduction project

N/A

[Calinou]

This is most likely shader compilation stutter. To prevent this stutter, you need to display the effect for 1 frame in front of the camera when the game loads to make the shader compile in advance. The effect can be located behind a solid mesh, but it must have its visible property set to true and must not be frustum or occlusion culled (hence the need to be in front of the camera).

When using GLES3, you can also enable asynchronous shader compilation and caching, but it won't work well on all GPUs due to spotty implementations across drivers in OpenGL.

Switching to GLES2 may also reduce those stutters as shaders are less complex in GLES2, and therefore faster to compile. They won't completely go away though.

[MarkoKrsic]

Thank you for the quick respons Calinou, I will do some testing and get back to you. Why is it not affecting Linux in the same way though? It's a 2-3 second freeze almost on Windows while on Linux it's a frame dip for a fraction of a second.

[smix8]

If you have enabled or use any multi-threading in Godot 3.x and Windows the Visual- and PhysicsServer will act as a multiplier to ruin your framerate further (or extend any frame freeze). The property tooltip in the ProjectSettings for multi-threading has a harmless sounding tooltip that it can add "some stutters" but in reality it is a stutter-tsunami when framerate is already low.

[Zireael07]

The fact that Windows is more affected makes me think of another issue: #33969

[MarkoKrsic]

So I changed all of the instances of Sprite 3D that were backlit and front lit by omnilights to CPU particles. The issue is gone on Windows and both Windows and Linux are seeing 50-100% increases in FPS rates. This solves my issue for now but still leaves the question why was Linux able to breeze through those loads while Windows was near freezing the game. I can close or investigate further if warranted. Thank you all for keeping me on my toes and experimenting until I figured out what the bottle neck was on my end.

[Calinou]

If you can create a minimal reproduction project that exhibits the issue, we may be able to look further into it. Otherwise, this issue should be closed as we have no easy means of investigating the issue (especially since no contributor has been able to reproduce the issue on their own system so far).

[clayjohn]

This does sound like shader compilation stutter. Windows has notoriously bad OpenGL drivers. Some users have worked around this by using ANGLE to circumvent the bad drivers.

With GPUParticles you are compiling two shaders when they first become visible which increases the stutter.

There are options in the Project settings to implement shader aching and async compilation which can help on some systems.

The best solution is to force shader compilation during a loading screen by showing each object with every combination of materials so that shader compilation happens at load time.