Time Nick Message 11:52 MTDiscord Again a reminder for reviewing #12828 and re-reviewing #13020 11:52 ShadowBot https://github.com/minetest/minetest/issues/12828 -- Add vector variation for ContentFeatures 'visual_scale' property. by Andrey2470T 11:52 ShadowBot https://github.com/minetest/minetest/issues/13020 -- 3d line rendering. by Andrey2470T 11:58 MTDiscord I'm also awaiting for an approval of it 15:03 kilbith https://www.youtube.com/watch?v=w-NQAhmeOS8 15:03 kilbith just wanted to show you how good looking is this bloom 22:45 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1061415203989880842/image.png 22:45 MTDiscord Client render thread spends 25-35% receiving and unpacking network data 22:54 jwmhjwmh Any objections to #13017? If not, I might merge it soon. 22:54 ShadowBot https://github.com/minetest/minetest/issues/13017 -- Implement `minetest.get_node` and `minetest.get_node_or_nil` with LuaJIT FFI by TurkeyMcMac 23:04 sfan5 @x2048 surely that's only because you lots of block updates? 23:09 sfan5 jwmhjwmh: I'm still not wholly convinced of that the extra complexity and less maintainability is worth it but don't mind that 23:10 MTDiscord sfan5: well yeah, view range of 600 and 8 meshing threads. 23:10 MTDiscord Drops to 15% with autodetected number of threads 23:14 jwmhjwmh I'll leave it unmerged for now. 23:15 sfan5 well that doesn't have any purpose 23:15 sfan5 if other devs want it in and I'm roughly neutral on it then it should go in 23:29 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1061426312033611877/image.png 23:30 MTDiscord More fun statistics. Adding blocks to the meshing queue (+caching them) takes majority of the time in client packet handler, and ~50% of that is waiting for the mutex 23:30 MTDiscord Looks like I've introduced a lot of contention on the MeshUpdateQueue by adding more threads... 23:33 sfan5 question is where 23:33 sfan5 I should profile this 23:35 MTDiscord MeshUpdateQueue::addBlock 23:36 MTDiscord versus MeshUpdateQueue::pop 23:36 MTDiscord Both methods copy a lot of data around while holding that mutex 23:37 sfan5 yeah that's what I suspected 23:37 sfan5 the cacheBlock call should be taken out of it 23:37 MTDiscord I wonder why we need it at all 23:37 MTDiscord Can we lock the map's blocks and pass them byref? 23:38 sfan5 aside from the fact that the mb itself can get deallocated, locking each mb is way too fine-grained and ruins performance 23:40 MTDiscord I meant using exising refGrab() / refDrop() to keep the blocks in memory while mesh is generated 23:40 MTDiscord This is cheap and can be done before queueing, then released when client receives the mesh. 23:41 sfan5 are mapblocks ever replaced with new objects? 23:41 MTDiscord nope 23:41 MTDiscord Only unloaded when the timers expire 23:41 sfan5 what if the data changes while it's being generated? 23:42 MTDiscord This means the client thread will queue regeneration of the mesh shortly after 23:42 MTDiscord Either because data arrived from the net or because of prediction (build/dig) 23:42 sfan5 so it doesn't matter if the result is junk? hmm 23:43 sfan5 I forsee the meshgen crashing though if data is not consistent between reads 23:44 MTDiscord Meshgen will still use vmanip 23:44 MTDiscord we'll just populate it from real mapblocks instead of CachedMapBlock 23:44 MTDiscord MeshUpdateQueue::fillDataFromMapBlockCache 23:45 sfan5 hmm 23:51 MTDiscord https://github.com/x2048/minetest/tree/main-thread-performance - here's the version with the time measurements