Time Nick Message 13:50 Zughy[m] wait, wasn't the next meeting planned for today? In the wiki says "2022-??-??" 13:50 Zughy[m] https://dev.minetest.net/Meetings#2022-.3F.3F-.3F.3F 13:51 Zughy[m] sorry I meant for the 24th, not for today 13:52 Zughy[m] https://irc.minetest.net/minetest-dev/2022-04-10#i_5959082 13:52 erle today is the ??th day of the ??th month of 2022 you say? 15:55 Baytuch Good evening, MineTest devs 19:30 erle uh, so does anyone of you need the 2 unused bits in the plantlike drawtype meshoptions for anything? 19:31 erle because i just did a lot of work just to get some crops a bit lower and it still does not fully work 19:37 erle my proposal would be to use at least one bit for a fixed -y offset of 1/16 node and maybe the other one for a -y offset of 2/16. that way, 15/16 14/16 13/16 lowered farming soil could easily (i.e. without nodebox trickery) have plants on it. also the same node could be planted on normal dirt and lowered farmland. 19:37 erle the current random -y offset is nice for plantlikes on full nodes, but kinda useless if you have a gap below it 19:37 erle also, my melon and pumpkin stems are now + instead of x because i can't rotate nodeboxes 19:47 MTDiscord your not using the right drawtype 19:49 MTDiscord try "degrotate" 19:55 erle Jonathon thanks 19:57 erle Jonathon could you point me to an example of degrotate for nodeboxes? 20:01 erle Jonathon the documentation says that degrotate is only valid for plantlike and mesh drawtypes. is the documentation lying? 20:05 sfan5 I just posted on the Irrlicht forum to make them aware of most of the fixes we applied to IrrlichtMt 20:07 erle nice, show 20:07 erle pls 20:08 erle do all their contributors post on a sourceforge forum? i thought they were using mailing lists or something 20:08 erle or where is it hosted 20:12 sfan5 its on irrlicht.sourceforge.io 20:14 MTDiscord https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819 <- nice 21:45 erle > We forked because waiting for an upstream release to fix many issues that have been plaguing users for years was no longer feasible. 21:45 erle does irrlicht even make releases? 21:45 erle like, regularly 21:46 MTDiscord no 21:46 MTDiscord *releases yes, regularly no 21:46 erle i mean maybe, just maybe, irrlicht is just a “trunk”-only project now https://irrlicht.sourceforge.io/?cat=9 21:47 sfan5 that's missing 1.8.5 21:47 erle yeah i noticed 21:51 erle sfan5 for the core affinity thing, why did you not set the core affinity to the core the task is already running on instead of removing it? or is there more to it than “prevent a spurious thread core switch”? 21:52 erle (as i said before, the comment in the irrlicht source code is most likely wrong – the thing is for processors that count time differently, not bios bugs) 21:52 sfan5 you want to know why I removed an obsolete workaround instead of keeping it but mitigating its impact? 21:52 erle well, it's not obsolete, given that both fleck and me seemed to have multiple machines that have that 21:52 sfan5 you never mentioned this but I also I don't believe you 22:06 erle sfan5 sorry, my internet is shit. i am going to explain the reason for the workaround now. 22:06 erle though i am *really* sure i did it before 22:06 erle maybe not to you 22:07 erle sfan5 did you read all the windows articles i posted back then when i claimed the thread affinity thing is wrong the first time? 22:08 sfan5 just explain what you want to explain 22:10 erle okay, so as far as i know, this workaround is necessary because some stuff is implemented differently for the TSC register in different processors. the thing originally ticked with every clock cycle, allowing you to make accurate timing measurements. 22:10 erle when multicore processors came, there was no guarantee that they would tick the same due to powersaving etc. – what if you shut a core down? 22:16 erle so you have basically three possible ways this can go 22:16 erle 1. timing ticks are coupled to clock frequency. this works for time measurements as long as no powersaving is going on. 22:16 erle 2. timing ticks are constant. you can check the processor flags on linux for constant_tsc. this means that *per processor* you can rely on the timing even if there is powersaving going on and the cpu freq is reduced. 22:16 erle 3. tsc is shared between processors in multicore systems. this is the newest, and of course, the thing that makes the workaround not necessary. 22:16 erle sfan5 as mentioned before, i think you removed that affinity call because it pinned the thread to core 1, regardless if that core was ever the core on which it run before. is that correct? 22:17 erle as literally *all* of the docs i read say, the correct solution is to pin it to the core it is on, otherwise on multicore systemss your timing is off if the thread switches cores at the right … well, time. 22:17 sfan5 if you want to say that (recent) windows does anything other than 3 then microsoft's docs contradict you 22:18 erle no, on linux you can easily figure it out if your system is affected 22:18 erle look if you have the cpu flag tsc_reliable 22:18 erle if you do not have it, there is no reliable TSC 22:19 sfan5 I must have missed the part where we're talking about Linux 22:19 MTDiscord not my fault you're using nigh on 20 year old hardware 22:19 sfan5 https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps 22:19 sfan5 if you read this it tells you that windows synchronizes the stuff that QPC is based on 22:19 sfan5 zero exceptions 22:19 erle ; Systems with flawed firmware that run these versions of Windows might not provide the same QPC reading on different cores if they used the TSC as the basis for QPC. 22:22 sfan5 "these versions of Windows" = pre-Vista 22:22 sfan5 are you trolling? 22:22 erle the only thing that is bios-relevant here is that windows is stupider than linux 22:22 erle and asks the bios instead of measuring itself 22:24 erle anyway, the newest documentation that i could find that said to pin it was from 2018 and the last processor where i was positive that TSC was not synchronized was made around 2016 or so? 22:24 sfan5 I will trust Microsoft's documentation over you saying you found something somewhere 22:24 erle regardless, i asked fleck to check that some time back because he had 2 identical systems that did not have reliable timing 22:25 erle microsofts documentation says you do not *need* to, but everywhere where it talks about multicore, it says you can get wrong measurements 22:25 sfan5 no it does not 22:26 erle btw, the info that some processors implement it ”incorrectly” that comes up often is wrong. it is merely that the meaning of some timing stuff (not only TSC) changed over time, especially regarding powerssaving and multicore. 22:27 sfan5 > Does QPC reliably work on multi-processor systems, multi-core system, and systems with hyper-threading? 22:27 sfan5 > Yes 22:27 sfan5 they even added a FAQ entry for people like you who think they are smarter 22:29 erle obv the correct answer is measuring it 22:29 sfan5 yes please waste your time with that 22:30 erle i believe fleck has 2 identical systems that have no invariant TSC and i'll ask about it 22:30 MTDiscord continue wasting time by chasing shadows 22:31 sfan5 that's cool but please don't report the results here because an invariant TSC has nothing to do with whether QPC works correctly 22:33 erle oh i remember again 22:34 erle forget about it for now. the windows documentation for QPC is most likely wrong, but until you get a test program, you won't believe that. so if i ever bring it up again, it will be with a test program. 22:34 MTDiscord sfan5, i've been working on a mapgen that does a heavy amount of pregeneration at startup 22:35 sfan5 you can report documentation bugs to microsoft (on github even IIRC), do that first if you find anything 22:37 sfan5 hmm are you sure a mapgen is supposed to do pregeneration? 22:37 MTDiscord yes, i've got a river algorithm that behaves fairly realistically that requires a monster startup period 22:37 MTDiscord https://cdn.discordapp.com/attachments/369137254641303560/965480872792973352/unknown.png 22:39 MTDiscord runtime generation speed is faster than v7 22:43 erle well, microsoft has been claiming that QPC will never return false or 0 on windows XP or later in their FAQ, even though searching for “QueryPerformanceCounter fail” yields accounts of people who not only had that happen, but can exactly say why it happens (QPC needs an *undocumented* 8-byte packing alignment or it fails). 22:44 erle but as i said, if i come back to this point, it will be with a test program. 22:44 erle because apparently this is as obscure as the shitty GCC x87 float implementation 22:55 erle Jordach how far out does the river algorithm precalc stuff? for the whole map? 22:56 MTDiscord the entire 62km^2 area 22:56 MTDiscord takes less than a few tens of kb totasl 22:59 erle Jordach is this a heightmap thing? i.e. you need to know where the valleys and hills are? 23:00 MTDiscord entirely heightmap 23:00 MTDiscord i also solved the problem that is 20m oceans 23:00 MTDiscord on average oceans can go for at least 1km to ~24km+ 23:01 erle well, i bet everyone will just LOVE that 23:01 erle in fact, i am looking forward to it 23:01 MTDiscord yeah and the default spawn algo is broken 23:01 MTDiscord i went back and fixed it 23:01 erle broken in what way? 23:01 MTDiscord it only seaches a few km at the world center 23:02 erle are you saying that there is a huge mountain or ocean there 23:03 MTDiscord all ocean 23:03 erle neato 23:03 erle Jordach so this map generator … is it in the room with us right now? 23:03 erle where can i get it 23:04 MTDiscord there's a branch on GH 23:04 erle link? 23:04 MTDiscord but beware of the fact that rivergen can get stuck in an infinite loop requiring SIGKILL at the minimum 23:04 erle uh what 23:04 erle why 23:05 erle there ought to be only a finite amount of state 23:05 MTDiscord sometimes there's a rare occasion where it decides to choose two points that are equi distant with identical height 23:05 MTDiscord the algo is even simpler than djkistra 23:05 erle so why is this not detected after a simple back-and-forth? 23:05 MTDiscord it does detect it and voids the entire river gen 23:05 MTDiscord i might just break it after x failed iterations 23:07 erle why void the entire etc. pp. 23:08 MTDiscord voids that river, not of the 64 23:08 erle ok ok 23:08 erle well that sounds manageable 23:08 erle like why would anyone care about that one river 23:08 erle oh yeah, is it deterministic? 23:09 MTDiscord yes 23:09 erle nice 23:09 MTDiscord any more than 64 and the pain of n_rivers^(2^15) happens 23:09 erle lol 23:09 erle do you have some writeup on the thing so i don't have to get lost not understanding the code? 23:09 erle like how you arrived at it 23:11 erle jordach which branch of https://github.com/jordach/minetest is it? 23:11 MTDiscord yes 23:11 MTDiscord have a quick search 23:11 erle mg_reverb? 23:11 MTDiscord yes 23:12 MTDiscord just pay attention to the world co-ords 23:24 erle once again i lament that minetest incremental builds are not a thing. :/ 23:25 erle (branch switch = full rebuild) 23:34 erle Jordach a full rebuild stopped at shader.cpp.o: mt_opengl.h: No such file or directory 23:35 MTDiscord builds on my machine 23:36 erle nvm it was AGAIN the “we don't use submodules here, instead your build randomly breaks” story