Time  Nick      Message
12:54 hecks     do I need a mutex on meshes when using them? https://a.cockfile.com/K1R82X_aaaaaaa.jpg
12:54 hecks     I don't do anything that could modify them
12:55 hecks     just cloning and concating
12:55 hecks     and then drawing the result
12:56 sfan5     depends which class "owns" the meshes I'd say
12:57 hecks     MapBlockMesh
12:57 hecks     clientmap seems to have no problem drawing them without worrying about this
12:58 hecks     but I'm getting straight up memory corruption
12:58 sfan5     maybe the meshgen threads can modify them?
12:59 hecks     actually
12:59 hecks     I've got unrelated threads dying because of this, almost immediately
13:00 hecks     but gdb can continue past that point
13:04 hecks     there is a commented out mutex lock in the mesh gathering part of renderMap() but that mutex no longer exists
13:05 hecks     ah there we go, occasionally this pops up in the trace:
13:05 hecks     #8  0x00000000004941bb in MapBlockMesh::MapBlockMesh(MeshMakeData*, irr::core::vector3d<short>) ()
13:05 ShadowBot https://github.com/minetest/minetest/issues/8 -- Saplings + Growing Trees by MarkTraceur
13:05 hecks     oops
13:06 hecks     then another thread dies, this time it's emerge
13:37 celeron55 are you sure you're not using a pointer to something someone else in the same thread will delete?
13:38 celeron55 i wouldn't expect to stumble upon any locking issues as almost everything related to rendering is done in the main thread
13:38 celeron55 (due to irrlicht and old opengl, obviously)
13:42 celeron55 if it happens quickly, i would expect valgrind's memcheck to be useful
13:45 hecks     hold on, I think I've got indexing issues due to c++ modulus not actually being modulus
13:46 hecks     that may have trashed stacks
14:19 hecks     The mesh pointers are being relocated every frame somehow...?
14:25 celeron55 well, the meshes can be re-generated for various reasons
14:25 celeron55 in which case the entire MapBlockMesh is replaced with a new one
14:26 hecks     but every frame, on a completely featureless flat map?
14:26 hecks     let me stop time as well
14:26 celeron55 yeah it happens to get the mapblock edges right
14:26 celeron55 as when a new one comes in it can affect the generation of its neighboring ones
14:27 celeron55 once there are no transfers going on there should be no mesh generation happening
14:28 hecks     and yet the pointers keep coming
14:28 celeron55 as you can probably imagine there's a "tile wall" of sorts between each mapblock, which is affected by both mapblocks and is handled currently as being part of one of the mapblocks
14:29 hecks     now the pointers keep repeating
14:29 hecks     as if something was double buffered
14:31 hecks     that's what it looks like:  190558256 to 206981200, 206981200 to 190558256, repeat
14:31 hecks     this is an irrlicht object and who knows how it's being allocated
14:31 hecks     but... pointers shouldn't be yanked from under anyone
14:33 hecks     hmmmmm wait
14:33 hecks     could those be tile layers
14:33 hecks     no that's stupid
14:33 hecks     but then again MapBlockMesh::m_mesh is an array
14:38 hecks     it shuts up when I look at the sky or the ground
14:47 hecks     aaaaaah, more indexing gremlins
14:47 hecks     signed mapblock positions are a loaded gun
14:57 hecks     ok, so curiously, the trivial case of 1x1x1 batches (no-op) works
17:03 oil_boi   1x1x1 mapblocks?
17:12 hecks     yes
17:12 hecks     so I'm getting this stuff to finally draw, but it's still crashing
17:15 hecks     and, oops, didn't set ehm_static
17:31 hecks     so now it draws and it draws FAST, without even frustum culling
17:31 hecks     but why the segfaults
17:32 hecks     must be std maps being lousy
17:32 hecks     gdb is being very vague about where it's dying, how do I make it less vague?
17:34 Kimapr    catchsegv?
17:35 hecks     sigsegv
17:35 hecks     but all it gives me is a function name, and it's not even consistent with that
17:36 hecks     that, or it's dying in more than one place
17:48 hecks     okay, exciting; it stopped crashing
18:00 Krock     what are we going to to about the jumping issues?
18:00 Krock     sfan5, rubenwardy ?
18:00 Krock     it's blocking the release and that must somehow be solved...
18:02 Krock     from testing, the two PRs in combination provided acceptable results. yet not perfect, this could probably be turned in 5.4.0-dev?
18:02 Krock     *tuned
18:05 hecks     works https://a.uguu.se/LnWRE4D0wDQw_batched.jpg
18:05 hecks     most of the batches have been trimmed, mesh drawing is now a pitiful 0.4ms
18:06 hecks     now todo: trim the fat from that "preprocess" step, and fix the glitches
18:06 Krock     deadbeef
18:07 hecks     had to give the dev exe a bogus hash to differentiate it from all the other minetest executables I have installed
18:26 sfan5     Krock: the fixes are not perfect? I didn't notice anything in that direction
18:30 pgimeno   hecks: nice progress!
18:30 sfan5     in any case 5.3.0 is fine to release with both of those fixes IMO
18:39 Krock     hmm, looks like it's luck based
18:39 Krock     https://krock-works.uk.to/u/movement-2020-07-05_20.33.27.mp4 <-- master
18:40 Krock     https://krock-works.uk.to/u/movement-2020-07-05_20.36.11.mp4 <-- 5.2.0-dev
18:40 Krock     sorry for bad VPS
18:43 hecks     it's framerate based
18:49 sfan5     I have a stable 60 fps here and zero issues fast-climbing
18:54 Krock     sneak glitch no longer works?
18:54 Krock     alright okay
18:56 Krock     nvm. applies the object properties in the wrong place
19:30 hecks     back to the other problem, why does mapblockmesh give me a new mesh every frame
19:31 hecks     I'm just walking in circles or moving the camera, there's no animation going on, time is stopped
19:35 Krock     are you sure that it's regenerated, and not just recycled? the cache hit should be next to 100%
20:02 hecks     The pointer is different, that's all I know
20:02 hecks     another curious thing: mesh making ms in the profiler is almost constant
20:02 hecks     2ms every frame even though this is a flat server with nothing to do
20:03 hecks     so what that does is... it consumes the mesher queue
20:03 hecks     updateBlock is what feeds it
20:09 hecks     so this is triggered by handleCommand_BlockData
20:09 hecks     by network?
20:10 hecks     if I comment that call out, it doesn't do that any more
20:10 hecks     and while I have to nudge mapblocks so that they appear, they're good now and framerate is in the triple digits
20:14 celeron55 the server is sending mapblocks to the client that it thinks have updated in some way
20:20 hecks     but there's literally nothing to update...
20:20 hecks     and
20:20 hecks     I fired up 5.2
20:22 hecks     this... doesn't look good https://a.uguu.se/biGdlksszRN1_mesherms.jpg
20:22 sfan5     9ms to generate a single mesh once?
20:23 hecks     no, this is all mesher work for the frame
20:23 hecks     but there's absolutely nothing for it to work on, and it's receiving packets for it too
20:23 hecks     this is very very bad
20:24 hecks     let's say I'm getting 100 FPS, 5ms drawtime for this trivial scene
20:24 hecks     4.9ms of that is the MESHER
20:24 hecks     well okay, maybe not
20:24 hecks     the skybox is also eating some
20:31 sfan5     with devtest in a flat world I get exactly zero mapblock updates when not doing anything
20:34 hecks     what about the mesher
20:35 sfan5     can't find it in the profiler
20:35 hecks     Client: Mesh making, are you sure it isn't there?
20:36 sfan5     oh it's there, but not showing any values
20:37 hecks     same machine or dedicated server?
20:37 sfan5     singleplayer
20:40 hecks     something was up with the profiler print interval, now it's printing a more sane value
20:40 hecks     but there's still mesher work unaccounted for
20:45 hecks     well okay, 5.2 is kind of normal with a truly minimal setup, with a send range of 1
20:47 hecks     but I don't have my mesh comparer there to really verify it
20:47 hecks     now the same setup in 5.3 still remakes meshes that have no business being remade
20:50 hecks     block send distance of 1, stationary, flying
20:50 hecks     *still* re-sending blocks
20:55 hecks     only when I fly far enough above the map to not have any geometry within the send distance, that's when it stops
20:57 hecks     currently trying to understand how blocks are picked for sending, and I can't find any "dirty" condition
21:15 hecks     okay so SetBlockNotSent is the dirty bit
22:21 paramat   merging #10025
22:21 ShadowBot https://github.com/minetest/minetest/issues/10025 -- Apply camera smoothing to 'not touching_ground' stepheight by paramat