Rendering Performance

michael314
New member
 
Posts: 6
Joined: Fri Jan 12, 2018 03:39

Rendering Performance

by michael314 » Fri Jan 12, 2018 18:06

In general I don't see very good performance when Minetest is rendering, even on a decently fast machine. The strange thing is, rendering speed seems about the same on different devices with wildly different benchmarks. Rendering full screen or in a smaller window doesn't seem to make much difference either. It seems like there is some minimum amount of processing power Minetest requires for decent performance, but it doesn't make much use of anything beyond that.

For example, one device with CPU passmark 3500, GPU passmark 580 versus another device with CPU passmark 7000 GPU passmark 3000 (so roughly 2x CPU speed, 5x GPU speed by those benchmarks), I am seeing in the range of 40-60fps on both devices with similar terrains and resolution. But even though I am getting a decent fps, the actual drawing (initial rendering?) of the scenery happens really slowly on *both* computers. I mean, using fast fly I can push up close to the edge of what is being rendered and not be able to see anything in the distance. If I stop moving, it doesn't even render evenly up to the edge of the fog, and frequently there are gaps even as I get close to something, especially in water areas where I can actually see glimpses of stuff underground because it hasn't rendered the sea floor yet.

If I use the "r" option I can see that a certain amount of scenery gets rendered before the oldest stuff gets thrown away. I presume this is due to memory restrictions. The thing is, it's not a whole lot! I have hit "+" to bump render distance out to almost 2000, yet I only see a radius of about 100 rendering around me as I move. Overall, if I travel about 1000 units out and then come back with a total width of about 200 that is the total it will render before stuff gets lost. That's a volume of around 10M if I'm not miscalculating. It wouldn't be that bad if it would actually render out to the distance specified (2000 versus 200, for example) but it would have to do it a lot faster.

Maybe I just have inflated expectations, I dunno.
 

User avatar
Krock
Developer
 
Posts: 3784
Joined: Thu Oct 03, 2013 07:48
Location: Switzerland
GitHub: SmallJoker

Re: Rendering Performance

by Krock » Fri Jan 12, 2018 18:27

Starting with this, very easy point:
michael314 wrote:yet I only see a radius of about 100 rendering around me as I move. Overall, if I travel about 1000 units out and then come back with a total width of about 200 that is the total it will render before stuff gets lost.

The client can not render what it doesn't know. Mapblocks (16*16*16 nodes) are sent to the client (even in singleplayer) in a certain range. The setting is documented here - 10 * 16 nodes matches quite much with your guessed 200 metres/nodes. Note that this setting only affects generated mapblocks. If you want to see further without walking, also increase the block generate distance.
To prevent mapblock unloading, adjust this setting (value in seconds) in your minetest.conf or using the Advanced Settings dialog in the main menu.
Mod Search Engine - Mods by Krock - DuckDuckGo mod search bang: !mtmod <keyword here>
 

User avatar
sorcerykid
Member
 
Posts: 673
Joined: Fri Aug 26, 2016 15:36
Location: Illinois, USA
In-game: Nemo

Re: Rendering Performance

by sorcerykid » Fri Jan 12, 2018 19:21

Krock, those are great explanations for the client-side. But I'm also curious about the server-side of things.

If a player approaches a mapblock and it gets loaded into memory, and then the player logs off, how long will that mapblock be retained in memory on the server? What actions will cause a mapblock to be loaded back into memory, outside of the scope of a player? I know it's possible with the voxel manipulator, but will get_node and/or set_node work too? And in those situations, what configuration setting determines the lifetime of the mapblock before it is unloaded by the server?

Thanks for your insight :)
 

User avatar
Krock
Developer
 
Posts: 3784
Joined: Thu Oct 03, 2013 07:48
Location: Switzerland
GitHub: SmallJoker

Re: Rendering Performance

by Krock » Fri Jan 12, 2018 19:39

This quickly escalated to a Q&A topic. I don't mind, so here some answers:
sorcerykid wrote:how long will that mapblock be retained in memory on the server?
[...]
And in those situations, what configuration setting determines the lifetime of the mapblock before it is unloaded by the server?

Analogous to the client's setting "client_unload_unused_data_timeout", there's "server_unload_unused_data_timeout", which defaults to 29s. 29 is a prime number to spread the load, the very same idea as behind the server map save interval of 5.1s (3*1.7 or 0.3 * 17, both are uncommon numbers).
sorcerykid wrote:What actions will cause a mapblock to be loaded back into memory, outside of the scope of a player?

You can forceload blocks. However, you'll need a mod to put this functionality into a chat command or something other practical.

sorcerykid wrote:will get_node and/or set_node work too?

No, they only work for already loaded mapblock data.

@michael314
How about the single core rating of these two processors? Minetest loves strong cores, as we can only make use of one at the moment.
Mod Search Engine - Mods by Krock - DuckDuckGo mod search bang: !mtmod <keyword here>
 

User avatar
sorcerykid
Member
 
Posts: 673
Joined: Fri Aug 26, 2016 15:36
Location: Illinois, USA
In-game: Nemo

Re: Rendering Performance

by sorcerykid » Fri Jan 12, 2018 19:52

Wow that's invaluable information, thanks so much for your expertise. It's going to help me a lot in optimizing my server. I'd heard about force loading before, but I wasn't aware it was a builtin function. If you don't mind me asking, what is the second parameter for? The description is a bit confusing to me. Does it make it possible to keep the block in memory indefinitely?
 

michael314
New member
 
Posts: 6
Joined: Fri Jan 12, 2018 03:39

Re: Rendering Performance

by michael314 » Fri Jan 12, 2018 20:28

Krock wrote:This quickly escalated to a Q&A topic. I don't mind, so here some answers:
@michael314
How about the single core rating of these two processors? Minetest loves strong cores, as we can only make use of one at the moment.


It's really great that there are knobs to control all this stuff, thanks!

Single core we are looking at something like 1400 versus 1950 which is only 40% faster instead of 100%.

From what you've said, I assume the bottleneck is in loading the blocks, which is both CPU only and possibly slow due to being generated procedurally on demand instead of just being loaded from a file?
 

User avatar
ThomasMonroe
Member
 
Posts: 258
Joined: Tue Apr 04, 2017 16:21
GitHub: ThomasMonroe314
IRC: ThomasMonroe TMcSquared
In-game: ThomasMonroe TMcSquared

Re: Rendering Performance

by ThomasMonroe » Sat Jan 13, 2018 13:49

Krock wrote:@michael314
How about the single core rating of these two processors? Minetest loves strong cores, as we can only make use of one at the moment.


Is there a chance that MT will ever utilize more than one core?
Or is that already being worked on?
Projects| :Legends Of Survival: :improve MT graphics: :making people think:
I don't make things messy, I just disturb the local entropy.
 

User avatar
Krock
Developer
 
Posts: 3784
Joined: Thu Oct 03, 2013 07:48
Location: Switzerland
GitHub: SmallJoker

Re: Rendering Performance

by Krock » Sun Jan 14, 2018 10:06

sorcerykid wrote:Does it make it possible to keep the block in memory indefinitely?

Kind, yes. It simply specifies whether the server should keep the mapblock loaded permanently after a restart too.

michael314 wrote:I assume the bottleneck is in loading the blocks, which is both CPU only and possibly slow due to being generated procedurally on demand instead of just being loaded from a file?

You would need a lot of disk space to generate an entire world to load it all from the database. Generating an entire mapchunk (5*5*5 mapblocks = 80*80*80 nodes) takes not more than a second, unless you have some time-consuming Lua mods that run after the terrain generation. Namely that's biome_lib, most of the advanced Lua mapgen mods and perhaps also a few mobs mods.
Relevant: https://github.com/minetest/minetest/issues/3182

ThomasMonroe wrote:Is there a chance that MT will ever utilize more than one core?
Or is that already being worked on?

The possibility exists but the problem is that Lua alone is limited to a single thread. Multiple threads are possible but mods that run on different ones do not have direct access to each other (isolated execution). Currently there's nobody working on this - heck - at this moment there are 785 other, reported issues.
Mod Search Engine - Mods by Krock - DuckDuckGo mod search bang: !mtmod <keyword here>
 

Byakuren
Member
 
Posts: 697
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri
In-game: Raymoo

Re: Rendering Performance

by Byakuren » Sun Jan 14, 2018 20:47

sorcerykid wrote:Wow that's invaluable information, thanks so much for your expertise. It's going to help me a lot in optimizing my server. I'd heard about force loading before, but I wasn't aware it was a builtin function. If you don't mind me asking, what is the second parameter for? The description is a bit confusing to me. Does it make it possible to keep the block in memory indefinitely?

The second parameter controls whether the forceload is "saved" between server restarts. If your mod already keeps track of what things should be forceloaded, then it should probably be set not to be saved to avoid problems if things aren't shut down cleanly.
Every time a mod API is left undocumented, a koala dies.
 


Return to Feature Discussion



Who is online

Users browsing this forum: No registered users and 3 guests