| Time |
Nick |
Message |
| 00:28 |
|
AliasAlreadyTake joined #minetest-dev |
| 00:30 |
|
YuGiOhJCJ joined #minetest-dev |
| 03:55 |
|
Menchers_ joined #minetest-dev |
| 04:09 |
|
izzyb joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:53 |
|
hmmmm joined #minetest-dev |
| 06:53 |
|
hmmmm joined #minetest-dev |
| 07:49 |
|
calcul0n_ joined #minetest-dev |
| 08:10 |
|
proller joined #minetest-dev |
| 08:21 |
|
hmmmm joined #minetest-dev |
| 08:21 |
|
hmmmm joined #minetest-dev |
| 08:27 |
|
hmmmm joined #minetest-dev |
| 08:27 |
|
hmmmm joined #minetest-dev |
| 10:24 |
|
Fixer joined #minetest-dev |
| 10:34 |
|
proller joined #minetest-dev |
| 10:43 |
|
appguru joined #minetest-dev |
| 11:52 |
MTDiscord |
<Andrey01> 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 |
<Andrey01> I'm also awaiting for an approval of it |
| 12:38 |
|
proller joined #minetest-dev |
| 13:38 |
|
appguru joined #minetest-dev |
| 13:48 |
|
appguru joined #minetest-dev |
| 13:49 |
|
rubenwardy joined #minetest-dev |
| 14:33 |
|
jwmhjwmh joined #minetest-dev |
| 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 |
| 16:09 |
|
appguru joined #minetest-dev |
| 17:38 |
|
olliy joined #minetest-dev |
| 19:02 |
|
Noisytoot joined #minetest-dev |
| 19:18 |
|
appguru joined #minetest-dev |
| 19:31 |
|
hmmmm joined #minetest-dev |
| 19:31 |
|
hmmmm joined #minetest-dev |
| 20:12 |
|
MTDiscord joined #minetest-dev |
| 21:00 |
|
jwmhjwmh joined #minetest-dev |
| 21:06 |
|
Guest27 joined #minetest-dev |
| 21:26 |
|
appguru joined #minetest-dev |
| 21:55 |
|
HuguesRoss0 joined #minetest-dev |
| 21:59 |
|
HuguesRoss joined #minetest-dev |
| 22:45 |
MTDiscord |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1061415203989880842/image.png |
| 22:45 |
MTDiscord |
<x2048> 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 |
<x2048> sfan5: well yeah, view range of 600 and 8 meshing threads. |
| 23:10 |
MTDiscord |
<x2048> 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 |
<x2048> https://cdn.discordapp.com/attachments/747163566800633906/1061426312033611877/image.png |
| 23:30 |
MTDiscord |
<x2048> 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 |
<x2048> 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 |
<x2048> MeshUpdateQueue::addBlock |
| 23:36 |
MTDiscord |
<x2048> versus MeshUpdateQueue::pop |
| 23:36 |
MTDiscord |
<x2048> 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 |
<x2048> I wonder why we need it at all |
| 23:37 |
MTDiscord |
<x2048> 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 |
<x2048> I meant using exising refGrab() / refDrop() to keep the blocks in memory while mesh is generated |
| 23:40 |
MTDiscord |
<x2048> 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 |
<x2048> nope |
| 23:41 |
MTDiscord |
<x2048> Only unloaded when the timers expire |
| 23:41 |
sfan5 |
what if the data changes while it's being generated? |
| 23:42 |
MTDiscord |
<x2048> This means the client thread will queue regeneration of the mesh shortly after |
| 23:42 |
MTDiscord |
<x2048> 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 |
<x2048> Meshgen will still use vmanip |
| 23:44 |
MTDiscord |
<x2048> we'll just populate it from real mapblocks instead of CachedMapBlock |
| 23:44 |
MTDiscord |
<x2048> MeshUpdateQueue::fillDataFromMapBlockCache |
| 23:45 |
sfan5 |
hmm |
| 23:48 |
|
Desour joined #minetest-dev |
| 23:51 |
MTDiscord |
<x2048> https://github.com/x2048/minetest/tree/main-thread-performance - here's the version with the time measurements |
