Vulkan: Heavy 3D scene (25M+ primitive indices) performs significantly slower in 4.0 compared to 3.5

[mrjustaguy]

Godot version

4.0 beta 5 & 3.5.1 stable

System information

Windows 11, Vulkan, GTX 1050 Ti 526.98

Issue description

The Stable release seems to run on avg about twice as fast as the 4.0 across various identical scenes, using only the features that are the same among the two branches (so no mesh lod, no ssao, ssr, occlusion culling or anything like that, just meshes and lights with no effects)

in the MRPs provided below, the converted and adjusted to match the original with 4.0 is getting 30-34 FPS depending on the renderer used @ 100% gpu utilization, while 3.5 is getting 60 fps @ 85% gpu utilization

Steps to reproduce

Test the Same Scenes across 3.5 and 4.0

Minimal reproduction project

4.0.zip
3.5.zip

[akien-mga]

It's a pretty pathological / unoptimized scene, but I can confirm the observed performance difference.

With an AMD Radeon RX VegaM on Linux (Mesa drivers), I get:

• 3.5.1-stable: 20 mspf
• 4.0-beta5: 45 mspf

Godot 4 reports 26 million primitive indices in the scene, with 730 MeshInstances of the same heavy mesh.

[clayjohn]

I compared the scenes as well. Initially I got similar results, but then I did two things:

1. I disabled vsync in both projects (as both MRPs have Vsync enabled)
2. I ran the projects without running the editor as well

Vsync throws off frame time measurement and makes it not accurate. Running a scene from the editor means that you are measuring performance of the scene running on top of the entire editor and whatever scene is visible in the Viewport. Right now the Vulkan 2D renderer is more performance intensive than the 3.x 2D renderer which may explain why your GPU is getting saturated running both the editor and the scene.

That being said, after taking both of those steps 3.x still performed faster for me:
3.x: 2.28 ms
4.0 (forward plus renderer) 3.47 ms

This is a pretty big difference and looking at the visual profiler it appears that all the time is spent in draw calls (depth prepass and opaque pass). This highlights the 4.0 forward_plus scene shader being slower than the 3.x scene shader.

Altogether a difference of 1 ms is not unexpected as the forward_plus renderer is designed to scale much better to high numbers of objects and high numbers of lights. As a trade-off it has a higher base cost so simple scenes may perform worse.

I am not convinced that we are seeing a performance regression outside of the expected boundaries.

[mrjustaguy]

4.0 v2.zip
3.5 v2.zip

Here is v2 with 9 lights in the scene, performance scaling is much worse, with 17 fps vs 54 fps (4.0 vs 3.5)

As far as the scene goes, it's intentional to maximize the stress and make it as simple (tiny) to share and to make it as minimalistic as possible

[Calinou]

Try using the Vulkan Mobile renderer – it likely renders simple scenes faster, at the cost of rendering complex scenes slower.

[mrjustaguy]

in the v2, that one runs at 9 fps, and that's only with 8 lights working... this scene falls in to the complex scene category. opengl in 4.0 runs as well as the clustered renderer, albeit with no shadows in the v2

[Ansraer]

I don't have a current master build (spent all my free time moving instead of programming recently) but it looks like that something is indeed wrong when using a slightly outdated master version.
I initially assumed that the problem was that the scene was not complex enough and that the performance would scale better if I added more stuff, but that assumption was proven wrong after some further testing.
No matter what I did, 3.x always performed better than master all the way up to the point when my rx6900xt gave up.

Hope someone with more time than I can dig deeper into this, I would love to know what exactly is going on.