The pending VBO code

[MirceaKitsune]

Once upon a time (namely 5 days ago) there was a discussion about improving performance in Minetest. celeron55 mentioned the mapblock data is constantly streamed from the CPU to the GPU, which would be fixed by enabling Vertex Buffer Objects in Irrlicht (storing models on the GPU). Several people including myself tested it and noticed huge performance improvements... as far as 2 - 3 times more FPS in some areas.

However, VBO was disabled for a reason: It causes huge memory leaks, and minetest rockets up to over 1GB of RAM usage. The problem was partly fixed by clearing unneeded hardware buffers, which brought the leaks down to half. We soon we discovered the remaining leaks are due to Minetest intentionally storing mapblocks into memory for as long as 10 minutes (so the server doesn't re-send them if you return to an explored area). Reducing client_unload_unused_data_timeout to as much as 60 seconds fixes the RAM usage and makes VBO usable.

Sadly, this isn't the nicest way to fix it, although it does work and there's a comment in place on how to set it up. The correct way would be to cache mapblock data client-side (possibly on the drive) and have the video card only maintain what's being rendered. But since that's difficult to do and no one who can is around, the code to enable VBO is currently on hold. Not because it doesn't work as is, but because of the philosophy that "if we add it now no one will care to implement client caching later".

TLDR; There's a huge performance improvement but it causes memory leaks. Although ways to solve the leaks were found, they aren't the best, so the devs would rather not add the feature and wait for someone to implement client caching (rather unlikely).

Ok... so I'm all for good code and doing everything the right way. But I can't help being upset that there's a huge improvement which does work, but it's not merged to motivate people to implement it even better. I don't think this is going to force anyone to add client caching earlier than someone with the knowledge will be able to. Besides... client caching is a needed feature for other reasons too, such as storing chunks from servers and allowing a server to only send modified areas each time you log in. Anyway, the two purposes of this thread are:

- If anyone has the knowledge to implement client caching, and make the client send only what's being rendered to the GPU, please give it a try. My knowledge in C++ and Minetest code is way below what I'd need for something this advanced.

- Asking the developers to please not use the VBO code as bait to get this done sooner. Those of us with modern GPU's could really use twice more FPS. If it works, is disabled by default, and there's a note on how to enable it without the memory issue, let us have this improvement please. Someone will add client caching eventually, but until then we're sitting with a huge optimization under our noses.

If anyone's interested in the working VBO code, here is PilzAdam's commit which we're hoping to see upstream.

[PilzAdam]

MapBlocks are already cached in the client, they are not written to disk, though.

However, its a different feature and it is not really related to the VBO issue.

Also there were already 2 attempts to properly fix the VBO memory consumption:
1) Only mark the meshes as static when the mesh existed for 10 seconds (sine Minetest recreates the Mapblock meshes up to 4 times before they stay static); with this the performance increase is lost and the RAM usage wasnt increased, so its not good.

2) Drop the mesh of a MapBlock earlier than the MapBlock itself; this leads to massive problems with regenerating the meshes and would require to create a new system to generate meshes for existing MapBlocks, wich isnt quite trivial (someone could investigate here further, but I dunno if it really fixes the problem at the end).

[MirceaKitsune]

I see... I think I missed that part last time VBO was discussed. #2 is probably the way to go, but the issue remains when anyone can do it.

Also, based on #1: What would happen if instead, meshes would be marked as not static after they haven't been rendered for several seconds instead? Such sounds like it should work... there could be an option for the number of seconds also.

If that wouldn't work either, I maintain the opinion that until either can be fixed, your latest patch could go in (with the note to reduce client_unload_unused_data_timeout). If it's the best we can have so far, it shouldn't be shelved until the mapblock changes can be done... mainly cuz the improvement is way too big.

[paramat]

I saw the discussion and have been setting my timeout to 60 seconds as a mad random experiment. Not sure if it helps because i've been on another planet, stuff just goes so smooth on other realms ;)

[MirceaKitsune]

Almost two weeks, and the discussion fell into deadly silence. This... improvement... must... happen >:|

I'm bad at understanding graphics code so I don't know what else to try over the tests I already made. Option #2 in PilzAdam's comment sounds like the right way, and maybe someone else can investigate how it behaves in practice. It should be possible to control when a mapblock adds or removes its mesh, and IMO deleting a mesh after about 30 seconds of not rendering it should be more than ok.

Can anyone at least point out a function that runs each frame per mapblock, in which controls to add or remove the mesh can be placed? And what would be the functions to do so? I'll give it a try if I can have at least a base idea of how it works.

If no one who knows how to do this at all exists, I still suggest merging the code as is with the note to set client_unload_unused_data_timeout lower. It's off by default, and if some of us want to use it like this till a real solution is found why not let them?

[Inocudom]

If this results in lower CPU demands, I am in favor of it.

[PilzAdam]

with the note to set client_unload_unused_data_timeout lower.

Every server admin would kill you for this.

[MirceaKitsune]

Every server admin would kill you for this.

I'd sacrifice myself. Or, at least use VBO only in singleplayer till the better way is found :3

But thinking more in depth, I can see where the problem lies. When a mapblock exists in the client, its mesh automatically exists too. There's no judgement as to when the mesh of a mapblock should exist or not, and no telling between "I'm caching a mapblock so the server doesn't have to re-send it if the player comes back in a few minutes" and "I'm caching a mapblock so it's ready for rendering if the player suddenly turns around", which are different things.

I'm no expert in 3D code, but even to me this feels wrong from the start... with or without VBO. I don't even think it's Irrlicht's fault from this point of view, since if you give it a lot of meshes irresponsibly it will put them into the memory. It's also possible that storing so many unnecessary meshes is a cause for low performance ever since Minetest existed, though that I can't say for sure.

The way I think this should be done is: Mapblock data should be sent from the server to the client like it is currently, and stored for 10 minutes. However, the client should only create mesh data when a mapblock is also being rendered (the player sees part of it). If the player doesn't see the mapblock for a number of seconds (maybe 30 by default) the mesh should be removed and re-created when the player sees it again.

Should be doable with a few lines of code if only someone knows how to code this. I can try if anyone explains. I'm curious what results we'd get with 10 a minute data duration and 30 second mesh duration.

[VanessaE]

I've done a little bit of further testing with this.

Between the VBO code (linked here as a patch):

https://github.com/PilzAdam/minetest/commit/7af479cba466f801c5cb648c8a449877957cb723.patch

... and Exio4's "hardcode the value of 'e' " tweak:

cd minetestfolder
sed -i 's/exp(1.0)/2.718282/' client/shaders/*/*.glsl
# then copy the shader files over to your current install

...shaders are WAY faster on my box - to the tune of better than 40 fps, where I was getting 22 fps before, at the spawn on my server. Alternatively, I can increase my view range from 30 to about 60 or 70 and still get 25 fps. And this is with 256px textures with bumpmapping, mipmap+aniso+trilinear, etc all turned on.

Memory usage after 10 or so minutes of play was reasonable - maybe an extra 100 to 200 MB above what I'd normally see.

Both of these apply and work fine against git HEAD (as of today at least).

As Mircea said, this improvement must not be lost! It's too good to pass up.

[PilzAdam]

I've done a little bit of further testing with this.

Between the VBO code (linked here as a patch):

https://github.com/PilzAdam/minetest/commit/7af479cba466f801c5cb648c8a449877957cb723.patch

... and Exio4's "hardcode the value of 'e' " tweak:

cd minetestfolder
sed -i 's/exp(1.0)/2.718282/' client/shaders/*/*.glsl
# then copy the shader files over to your current install

...shaders are WAY faster on my box - to the tune of better than 40 fps, where I was getting 22 fps before, at the spawn on my server. Alternatively, I can increase my view range from 30 to about 60 or 70 and still get 25 fps. And this is with 256px textures with bumpmapping, mipmap+aniso+trilinear, etc all turned on.

Memory usage after 10 or so minutes of play was reasonable - maybe an extra 100 to 200 MB above what I'd normally see.

Both of these apply and work fine against git HEAD (as of today at least).

As Mircea said, this improvement must not be lost! It's too good to pass up.

Adding 2 things at the same time isnt really good. Whats the improvement of each of these alone?

[VanessaE]

Exio's tweak by itself gained me 3 or 4 fps, minimal but measurable. So that means the VBO code accounts for at least 15 fps or so. Last time I tried the VBO code, I saw little or no benefit from it, but I'm pretty sure I did something wrong then, as now it works beautifully.

[RealBadAngel]

since i have rebuild shaders and supporting code i will include this replacement with e constant
im cleanin now the testing code and gonna pull the commit in 2-3 days
btw, what exio gained i will lost with my code ;)

[MirceaKitsune]

Is there any news on this? Looked in latest master, and the VBO function is still commented out. I didn't notice the tweak mentioned above, but no doubt that the absence of VBO is still as palpable. Any chance we can find a solution to this somehow so VBO can be enabled, please?

[Inocudom]

Is there any news on this? Looked in latest master, and the VBO function is still commented out. I didn't notice the tweak mentioned above, but no doubt that the absence of VBO is still as palpable. Any chance we can find a solution to this somehow so VBO can be enabled, please?

You are with us again, MirceaKitsune. I suggest you go check out what RealBadAngel is doing. It might be worth your while.

[proller]

its also included in next

[MirceaKitsune]

You are with us again, MirceaKitsune. I suggest you go check out what RealBadAngel is doing. It might be worth your while.

He's doing a lot of (awesome) things, so I don't know what to check out.

its also included in next

That branch is a nice idea! Though I'm kind of afraid to use it, since many things there might be awesome but still not make it in master, so I might get disappointed :3 Nah I think I'll try it out, but I hope it does address features that will be merged.

[MirceaKitsune]

Aaaaand, many months have passed again. I'm still eagerly hoping for VBO support to further improve the FPS, but sadly there is no longer any news. I only heard that PilzAdam stopped maintaining it, so the code might already conflict in GIT and be dead for now.

I really don't know what to suggest. Poking the devs about it again is probably useless, I don't feel any are interested enough in this to finish it. If someone else could make the code compatible with latest master and fix any memory leak that's left, maybe then someone will finally add it. Anyone else willing to look into this again please?

[Inocudom]

Aaaaand, many months have passed again. I'm still eagerly hoping for VBO support to further improve the FPS, but sadly there is no longer any news. I only heard that PilzAdam stopped maintaining it, so the code might already conflict in GIT and be dead for now.

I really don't know what to suggest. Poking the devs about it again is probably useless, I don't feel any are interested enough in this to finish it. If someone else could make the code compatible with latest master and fix any memory leak that's left, maybe then someone will finally add it. Anyone else willing to look into this again please?

This feature is in Freeminer, which was once the next branch. Proller and xyz might be able to help you out, but they really aren't the easiest guys to reach.

[philipbenr]

@ Inocudom: That is unfortunately true. The devs need to be in contact with people to make a good game. I know this from experience.

[GingerHunter797]

I think that this should be added as soon as possible, if this really adds 2-3 times more fps than for people that only get 10-20 fps it would help a lot! But I have no idea how to do it so dont ask me...

[Inocudom]

I have very good news. CraigyDavi is now making Windows builds of Freeminer. The link to where they can be found is below:
http://forum.freeminer.org/threads/craigs-windows-builds-32-bit.124/
MirceaKitsune, this is your opportunity to test the VBO code that is in Freeminer and see how far it must go before it can be stable enough for Minetest.

[MirceaKitsune]

Oh my, look at the clock! It's time to revive the Minetest VBO support thread again!

Ok... I'm not trying to be annoying by bumping this thread every few months. It constantly comes back to mind as I notice that Minetest's FPS per draw distance is seriously not as good as it could be. This is such a simple optimization, and there's nearly no 3D engine that doesn't make use of it nowadays. Why can't we do it?!

Can we put some minds together and find a way to solve that memory usage problem? The last remaining issue was that, because mapblocks are persisted in the client, they are all put into the video RAM when this is enabled and cause high memory use. Maybe we can find some way to discard them, or only put those chunks being rendered into the video card, or anything else. Can we make this much needed feature happen?

[MirceaKitsune]

I'm very happy to announce that today, this year old struggle has been at last solved! RealBadAngel created a VBO patch that does not have the memory leak which plagued the old one. It was merged into master today, and people are reporting considerable performance improvements! This can finally be put to rest now.

https://github.com/minetest/minetest/pull/3763

https://github.com/minetest/minetest/co ... 3882d0c19b

[benrob0329]

Ooooh...I'll have to rebuild!

[MirceaKitsune]

Ooooh...I'll have to rebuild!

I tested it yesterday. Sadly I can't tell how big the improvement is, since at the same time adaptive draw distance was removed (I always used it). Certainly latest master feels very smooth however!

[Kevin Tee]

I test with it. With vbo enable I get 26-27 fps, disable 20-21 fps. Not so much.

[rubberduck]

but it is still something, and it is more than 25% faster in your case
(comparing to some stuff in blender that gets faster in 2.77: up to 22%, some only 5%)

and it is great with such "extreme modded" subgames like dreambuilder

[Kevin Tee]

but it is still something, and it is more than 25% faster in your case
(comparing to some stuff in blender that gets faster in 2.77: up to 22%, some only 5%)

and it is great with such "extreme modded" subgames like dreambuilder

Oh yeah, when you put it in terms of % then it is quite a lot. I just over expecting it to double the fps.