Minetest logo

IRC log for #minetest-dev, 2022-04-18

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
02:47 fluxionary joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
05:16 jonadab joined #minetest-dev
05:17 calcul0n joined #minetest-dev
05:48 sofar joined #minetest-dev
05:48 sfan5 joined #minetest-dev
05:49 Krock joined #minetest-dev
05:51 programmerjake joined #minetest-dev
05:54 cheapie joined #minetest-dev
07:03 proller joined #minetest-dev
07:08 proller joined #minetest-dev
09:06 Alias joined #minetest-dev
09:49 Fixer joined #minetest-dev
12:42 erle joined #minetest-dev
12:58 erle joined #minetest-dev
13:16 proller joined #minetest-dev
13:39 HuguesRoss joined #minetest-dev
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?
14:02 erle joined #minetest-dev
14:13 erle joined #minetest-dev
14:26 sometalgoo joined #minetest-dev
14:33 erle joined #minetest-dev
14:39 fluxionary joined #minetest-dev
15:02 erle joined #minetest-dev
15:11 kilbith joined #minetest-dev
15:26 behalebabo joined #minetest-dev
15:31 behalebabo joined #minetest-dev
15:40 kilbith joined #minetest-dev
15:55 Baytuch Good evening, MineTest devs
17:03 Desour joined #minetest-dev
18:40 fluxionary joined #minetest-dev
18:57 proller joined #minetest-dev
19:17 proller joined #minetest-dev
19:30 erle joined #minetest-dev
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 <Jonathon> your not using the right drawtype
19:49 erle joined #minetest-dev
19:49 MTDiscord <Jonathon> 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 <Warr1024> https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&amp;t=52819 <- nice
20:16 erle joined #minetest-dev
20:37 erle joined #minetest-dev
20:47 erle joined #minetest-dev
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 <Jonathon> no
21:46 MTDiscord <Jonathon> *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:05 erle joined #minetest-dev
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:08 PrairieWind joined #minetest-dev
22:08 olliy1or joined #minetest-dev
22:09 PrairieWind left #minetest-dev
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 joined #minetest-dev
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 <Jordach> 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 ; </proc/cpuinfo grep -o '[^ ]*tsc[^ ]*' |sort |uniq
22:19 erle constant_tsc
22:19 erle tsc
22:20 sfan5 that you found out something about the TSC register is cool and all but the API method does not directly read from there
22:20 erle linux can tell you if the thing is reliable. i think fleckenstein tried to get minetest run on windows to debug it. if he shows up again, i can ask him.
22:21 erle hey it says there right on the page
22:21 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 <Jordach> 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 panwolfram joined #minetest-dev
22:34 MTDiscord <Jordach> 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 <Jordach> yes, i've got a river algorithm that behaves fairly realistically that requires a monster startup period
22:37 MTDiscord <Jordach> https://cdn.discordapp.com/attachments/369137254641303560/965480872792973352/unknown.png
22:39 MTDiscord <Jordach> 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 olliy joined #minetest-dev
22:56 MTDiscord <Jordach> the entire 62km^2 area
22:56 MTDiscord <Jordach> takes less than a few tens of kb totasl
22:59 olliy1or joined #minetest-dev
22:59 erle Jordach is this a heightmap thing? i.e. you need to know where the valleys and hills are?
23:00 MTDiscord <Jordach> entirely heightmap
23:00 MTDiscord <Jordach> i also solved the problem that is 20m oceans
23:00 MTDiscord <Jordach> 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 <Jordach> yeah and the default spawn algo is broken
23:01 MTDiscord <Jordach> i went back and fixed it
23:01 erle broken in what way?
23:01 MTDiscord <Jordach> 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 <Jordach> 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 <Jordach> there's a branch on GH
23:04 erle link?
23:04 MTDiscord <Jordach> 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 <Jordach> sometimes there's a rare occasion where it decides to choose two points that are equi distant with identical height
23:05 MTDiscord <Jordach> 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 <Jordach> it does detect it and voids the entire river gen
23:05 MTDiscord <Jordach> i might just break it after x failed iterations
23:07 erle why void the entire etc. pp.
23:08 MTDiscord <Jordach> 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 <Jordach> yes
23:09 erle nice
23:09 MTDiscord <Jordach> 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 <Jordach> yes
23:11 MTDiscord <Jordach> have a quick search
23:11 erle mg_reverb?
23:11 MTDiscord <Jordach> yes
23:12 MTDiscord <Jordach> just pay attention to the world co-ords
23:12 AliasAlreadyTake joined #minetest-dev
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 <Jordach> builds on my machine
23:36 erle nvm it was AGAIN the “we don't use submodules here, instead your build randomly breaks” story

| Channels | #minetest-dev index | Today | | Google Search | Plaintext