Moore Threads: slow model rendering using the CPU fallback code

[illwieckz]

Not really a bug (no glitch), but I want to document the issue. I'll see if I can report it to Moore Threads.

I noticed that model rendering is very slow on the MTT S80, it is almost as slow as the CPU fallback code (r_vboModels off).

Edit: In fact it uses the CPU fallback code (see below).

At 1980×1080 resolution, the default plat23 spectator scene renders at 313 fps with the ondemand CPU governor and 355 fps with the performance CPU governor (the CPU is a weak AMD Ryzen 3 3200G):

But when rendering the 1920 1920 0 0 0 scene (that renders all the alien base), the performance jumps to 70~80 fps.

This makes it likely impossible to play with a resolution higher than 1920×1080 when playing with the ultra preset. This should be a decent gaming experience, but that's very weird to get such performance hit.

Here are some framerate comparison on this scene:

model code	CPU governor	framerate
GPU	ondemand	80 fps
CPU	ondemand	78 fps
GPU	performance	83 fps
CPU	performance	78 fps

• r_vboModels on:

• r_vboModels off:

[illwieckz]

GPU: MTT S80
CPU: AMD Ryzen 3 3200G (amd64)
System: Ubuntu 24.04.3
Kernel: Linux 6.8.0-100-generic
Kernel graphics driver: musa 3.1.0 (mtgpu)
OpenGL graphics driver: musa 3.1.0 (mtgpu)

Excerpt from gfxinfo:

GL_VENDOR: Moore Threads
GL_RENDERER: MTT S80
GL_VERSION: 3.2 build 20250122_master-227-gdf7bc68e
GL_SHADING_LANGUAGE_VERSION: 4.30

[illwieckz]

Actually it IS using the CPU fallback, as reported by the gfxinfo log:

Using GPU vertex skinning with max 41 bones in a single pass, some models may not be hardware accelerated. 

Despite providing GL 3.2 and GLSL 4.30, some limits are the same as OpenGL 2.1 and then most models are not GPU accelerated.

The game is a bit faster r_vboModels on because some tiny models may still be GPU accelerated.

[illwieckz]

Using cg_lowQualityModels on I recover the performance and get 228 fps on 1920 1920 0 0 0 viewpos:

So, actually, the efforts done to speed up the CPU fallback model code is actually beneficial to an actual PC gaming GPU on the market.

I do remind that even with cg_lowQualityModels on some models are still processed on the CPU because I couldn't trim down the number of bones for all models without breaking them. Basically on that plat23 scene, the barricade isn't accelerated (high amount of bones), but the acid tubes are (low amount of bones). Also the optimized models not fitting in GPU limits still use less bones to speed up CPU rendering, just not less bones enough to fit within GPU limits.

[illwieckz]

The ongoing work on OpenMP may actually benefit this use case as well, when the CPU isn't too weak.

[illwieckz]

With OpenMP I got 86 fps without cg_lowQualityModels! So this is an tiny improvement but an improvement:

I do remember that the CPU is weak.

On that weak CPU, the potential gain of OpenMP on the remaining CPU-processed models when using cg_lowQualityModels is not visible, it is still in the 220+ fps range, which is more than enough so it's fine.

[illwieckz]

I got 102 fps with OpenMP:

It looks like the rule of using half threads as available is good not only on 16-core/32-threads CPUs but also on 4-core/4-threads CPUs.

[illwieckz]

Also, with that thread configuration, OpenMP also shine when using cg_lowQualityModels by fastening the processing of “models that aren't low quality enough”, I now get 236 fps with OpenMP and cg_lowQualityModels combined:

[illwieckz]

Windows drivers for MTT GPUs is more recent, supposedly more featureful, so I don't know yet if such OpenMP trick would be useful on Wndows as well.

[illwieckz]

I forgot to say that all those tests were running with r_smp 1. With r_smp 0 I get 96 fps instead of 102 fps with cg_lowQualityModels off and OpenMP using 2 threads on that quad-core CPU.

[illwieckz]

I forgot to say that all those tests were running with r_smp 1. With r_smp 0 I get 96 fps instead of 102 fps with cg_lowQualityModels off and OpenMP using 2 threads on that quad-core CPU.

Actually, with this hardware it is only safe to bet on such speed bump from mixing r_smp 1 with OpenMP when rendering at 1920×1080 resolution (noted FHD below).

resolution	SMP	low Models	spectator rest	alien stress
FHD	off	off	380	97
FHD	off	on	380	239
FHD	on	off	358	102
FHD	on	on	358	238
2K	off	off	373	97
2K	off	on	373	238
2K	on	off	299	100
2K	on	on	299	226
4K	off	off	354	98
4K	off	on	355	239
4K	on	off	212	99
4K	on	on	212	225

Using SMP is actually a bit slower on 2K and 4K when there are plenty of models on scene, and much slower when there is no model on scene. Since rendering the game is more about rendering models, and that when models are on screen, SMP loss is smaller than SMP gain when it happens, SMP may still be an option. But SMP can be slower when only rendering the world, so for a single-player case exploring an open world, SMP may not be preferred, while a multiplayer arena game may prefer to disable SMP. Of course this test is about this specific GPU on this specific weak CPU.