Allow using VBOs for meshes all the way down to 4 vertices

[paradust7]

See minetest/irrlicht#287

[appgurueu]

I found the following claim:

No. In fact, VBOs used naively can be slower than client arrays (i.e. just re-streaming the geometry from CPU memory every frame).

Hence wasn't sure whether setting this as low as 4 would be a good idea. Won't this mean each particle gets its own VBO? That seemed excessive.

To test this hypothesis, I compiled a release build, and tested using the code from #14155. The results were roughly the same on this PR and master, so this seems to introduce no blatant performance issue there (on my hardware at least). If there was a performance issue, it'd probably be dwarfed by the many draw calls anyways.

[sfan5]

seems to work fine

[lhofhansl]

With my NVidia card I find no difference. Scene with viewing_range = 1000, client_mesh_chunk = 1. With or without this PR I get 6 FPS.

As comparison with client_mesh_chunk = 8 I get 60 FPS (now limited by my display)

But it didn't make things slower, so good, I guess.

[paradust7]

@lhofhansl

Raising client_mesh_chunk resolves the memory bandwidth issue because it makes the VBO's larger, so that they pass irrlicht's default test of 500. It may also be resolving other hidden performance issues as well. Are there any downsides to a higher client_mesh_chunk?

I generated another perf report after changing just the VBO limit, and it shows that rendering is now spending most of its time in state changes (25% just in setRenderStates3DMode, of which 20% is in OnSetConstants). I'm going to be looking into this as well. I'll also test client_mesh_chunk=8 to see what changes.

I am doing this performance tuning to improve the framerate specifically for VR, not necessarily high viewing range. For the VR experience to be really smooth, it needs to render twice (one for each eye) at 144 fps (so roughly the equivalent of 288 fps). (There are rendering techniques that combine the rendering of both eyes into one, but I'm trying to see how far I can get with separate passes)

[lhofhansl]

@paradust7 I think a larger client_mesh_chunk mainly reduces the number of drawcalls.

As you do perf reports on MT, could you do for large and small client_mesh_chunk sizes?
Increasing this is the single most significant performance settings.