Poor Performance - Godot 4.4 - 2D / Compatibility

Godot Version

v4.4.1.stable.arch.linux

Question

I create a new project using the Compatibility renderer. I add a player, implement movement, all goes well. Then I add a TileMapLayer. As soon as drag an image into the Tile Sources panel, the IDE grinds to a halt. Eventually it starts responding again, I add a texture to a 2D scene, I start the game - it freezes and takes about 90 seconds before it accepts input. After that the player can walk around on top of the texture normally.

Here are the specs of my laptop:

Processeur (Unité centrale): Processeur i5 Quad Core Intel® Core™ i5-8265U (1,60GHz, 3,9GHz Turbo)
Mémoire (RAM): 16 Go Corsair 2133 MHz SODIMM DDR4 (2 x 8 Go)
Carte graphique: INTEL® HD GRAPHICS (dépendant du processeur) - 1,7 Go max. de RAM vidéo DDR4 - DirectX® 12

Info about my GPU and driver:

$ lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620]
    Subsystem: CLEVO/KAPOK Computer Device 1323
    Kernel driver in use: i915
    Kernel modules: i915

$ glxinfo | grep -Ei 'device|memory'
    Device: Mesa Intel(R) UHD Graphics 620 (WHL GT2) (0x3ea0)
    Video memory: 15693MB
    Unified memory: yes
    GL_AMD_performance_monitor, GL_AMD_pinned_memory,
    GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, GL_EXT_memory_object,
    GL_EXT_memory_object_fd, GL_EXT_packed_depth_stencil, GL_EXT_packed_float,
    GL_AMD_pinned_memory, GL_AMD_query_buffer_object,
    GL_EXT_gpu_shader4, GL_EXT_memory_object, GL_EXT_memory_object_fd,
    GL_EXT_instanced_arrays, GL_EXT_map_buffer_range, GL_EXT_memory_object,
    GL_EXT_memory_object_fd, GL_EXT_multi_draw_arrays,

Here is the output that godot writes to the command line at startup:

$ godot
Godot Engine v4.4.1.stable.arch_linux - https://godotengine.org
Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). Using: 0
OpenGL API 4.6 (Core Profile) Mesa 25.1.6-arch1.1 - Compatibility - Using Device: Intel - Mesa Intel(R) UHD Graphics 620 (WHL GT2)

ERROR: TLS handshake error: -27648
   at: _do_handshake (modules/mbedtls/stream_peer_mbedtls.cpp:88)
mbedtls error: returned -0x6c00

Editing project: /home/myusername/new-game-project
Godot Engine v4.4.1.stable.arch_linux - https://godotengine.org
Inconsistent value (1) for DRI_PRIME. Should be < 1 (GPU devices count). Using: 0
OpenGL API 4.6 (Core Profile) Mesa 25.1.6-arch1.1 - Compatibility - Using Device: Intel - Mesa Intel(R) UHD Graphics 620 (WHL GT2)

(What is that TLS error?)

Anything I can do to speed this up? Is my graphics card just too slow? I am contemplating the purchase of a new laptop with a Radeon 890M, would that solve the problem?

Edit: The texture file that I was dragging into the project, it was 1.6MB. When I work with a smaller file of 87KB, that seems to fix the problem. I would still be interested in any feedback on the above - is this configuration okay? What is that TLS error?

A TLS error should seemingly be an error relating to key exchange for https connection or something similar.
JPEG textures can look small from a file size pov, but they can decompress to be quite huge, which will definitely be an issue on a GPU limited system like yours.
Try to use power of 2 textures, of the smallest size possible to get desired visuals.
Textures and sprites pile up quick, and when targetting compatibility, implying you want to reach a wider audience, it’ll be harder for your game run on a wide ensemble of desktops and other devices harder if every texture is 1024x1024 or bigger.
Edit : Depending on what you’re displaying as small as 32x32, 64x64, 128x128, 256x256 will be fine in 95% of cases, especially when using multiple textures on one mesh in 3d…
Btw, I used square power of 2 textures, but they can be rectangles. Using power of 2 helps with fitting and aligning your textures in CPU and GPU memory

Have fun,
Cheers !

3 Likes

Awesome. Thank you.

Btw the TLS error not sure if it’s really resolved as they say on GitHub, but since you are on Linux, this might be of interest.
Pretty sure I’ve seen it on win11 in a recent official build too…

1 Like

Many thanks for the info, and for the link. It looks like upstream mbedtls made a fix. Upstream godot had a workaround pending the fix, neither of which has yet made it onto my machine. Arch has multiple ways to install software including 1) pacman, which gives me the broken godot, and 2) flatpak, which gives me a fixed godot. The bug does not stop me from using godot, and usually the advice is to run godot from pacman, but in this case I might try switching to flatpak.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.