Large FPS drop at certain locations on RPi 400, caused by transparency sorting

[ixionine]

Minetest version

Minetest 5.6.0 (Linux)
Using Irrlicht 1.9.0mt7
Using LuaJIT 2.1.0-beta3
BUILD_TYPE=Release
RUN_IN_PLACE=1
USE_CURL=1
USE_GETTEXT=1
USE_SOUND=1

Irrlicht device

X11

Operating system and version

Raspberry Pi OS 64-bit (Debian 12 Bookworm)

CPU model

Broadcom BCM2711 Cortex-A72 (ARM v8) 64-bit SoC

GPU model

Broadcom VideoCore VI

Active renderer

OpenGL 3.1

Summary

While running the game Minetest Game, using 5.5.1 it runs at ≈25fps at the bad location listed below compared with a constant ≈3fps using 5.6.0. The FPS also drops significantly in DevTest. I used all the default settings while testing. I believe the slow down may be only occuring near water. I tried compiling quite a few versions of Minetest and it seems like the problem started with version 5.6.0. Version 5.5.1 doesn't seem to have the problem. I have tested the latest version 5.9.0 and it still has the problem.

Steps to reproduce

1. Create a new Minetest Game world with Mapgen v6, the default flags and the seed: 10943854337926371625.
2. Go to the location: 720,1.5,-276. FPS drops to ≈3fps.
3. Go to the location: 735,2.5,-295. FPS returns to normal ≈22fps.

[sfan5]

I'm not sure if the mapgen is deterministic enough to make the reproduction steps useful, but I don't notice anything on my desktop pc.

As a first step please collect and post the information shown by the game profiler (press F6).

[ixionine]

I haven't seen this problem occur on any other computer but it is consistent at least on the Raspberry Pi in my testing. I suspect the problem may be occurring where there is water movement as there is a lot in that location.

I have taken screenshots of the same location on 5.5.1 and 5.6.0 for comparison. Let me know if there is anything else I can post that will be helpful.

[SmallJoker]

Summary of the images above:

• Total frame time: 44 ms (average)
• solid meshes take 28 ms / ((1410 drawcalls/frame) / (12 frames)) = 238 us per drawcall
• transparent meshes take 217 ms / ((437 drawcalls/frame) / (12 frames)) = 6 ms per drawcall

Does the minetest.conf setting "leaves_style = opaque" make a major difference?

[sfan5]

Sounds like some graphics debugging with RenderDoc is in order. Note that you will need to use the ogles2 driver for this, so make sure to use 5.9.0 and compile with -DENABLE_GLES2=ON.

[ixionine]

I tested leaves_style = opaque and it didn't make any noticeable difference. I tried setting opaque_water = true and this did seem to stop the frame rate issue for 5.6.0 and 5.9.0 at that location. These are the numbers I get with that setting:

	default	opaque
5.5.1	23fps	24fps
5.6.0	3fps	24fps
5.9.0	2fps	29fps

5.9.0 has some other very low frame rate spikes when moving around which older versions didn't have but the low FPS is only temporary. This problem however is a constant very low frame rate.

Thanks for the help. I'll have a look at setting up RenderDoc.

[ixionine]

So I've compiled Minetest 5.9.0, enabled ogles2 and installed the Debian package of RenderDoc. Is there anything else I should do or just upload a capture?

[sfan5]

Try uploading a capture of the problematic place with low fps, yes.

[ixionine]

Here is the capture with low frame rate.

bad-framerate.zip

[sfan5]

So this scene has about 34k draw calls which is not good but not out of the ordinary for MT. I quickly looked at rendering-related changes between 5.5.0 and 5.6.0 and nothing really caught my eye.

Edit: nevermind. I took a proper look at the profiler data and the time drawing solid meshes is pretty much the same. However 5.6 uses 217ms for transparent meshes. Unfortunately the "vertices drawn" isn't accounted correctly so we can't draw conclusions from that. git blaming relevant code points at b0b9732359d43325c8bd820abeb8417353365a0c

-> could you try transparency_sorting_distance = 0 and see if that fixes it? my guess is that transparency sorting is de-batching meshes to an extent that it breaks the performance. (empirically false)

Edit 2: ninja'd by @grorp

[grorp]

Well, 5.6.0 was the first release to contain https://github.com/minetest/minetest/commit/b0b9732359d43325c8bd820abeb8417353365a0c. If it's that, the problem should go away with transparency_sorting_distance = 0.

[randomMesh]

I don't know if this is related, but i can confirm that Minetest slows down really bad on my Raspberry Pi 5 if i walk near ice blocks.

[ixionine]

I can confirm transparency_sorting_distance = 0 fixes the problem. Thanks for finding the cause of it.