| Time |
Nick |
Message |
| 00:08 |
|
v-rob joined #minetest-dev |
| 00:37 |
|
proller joined #minetest-dev |
| 00:46 |
|
citrons joined #minetest-dev |
| 01:17 |
jonadab |
ROllerozxa: One of my favorites is "We're sorry, but your password couldn't be changed. Code: 0x8007052d". ย Which means your password is longer than the maximum allowable length, because *of course* there's a maximum allowable length, it's not like hashing it is going to make that irrelevant or anything. |
| 01:18 |
jonadab |
And yes, I found that out the hard way. |
| 01:33 |
|
[MTMatrix]_ joined #minetest-dev |
| 01:34 |
|
Niklp9 joined #minetest-dev |
| 01:36 |
|
sugarbee1 joined #minetest-dev |
| 01:37 |
|
ROllerozxa_ joined #minetest-dev |
| 01:46 |
|
Sokomine joined #minetest-dev |
| 02:47 |
|
proller joined #minetest-dev |
| 04:02 |
|
proller joined #minetest-dev |
| 04:13 |
|
v-rob joined #minetest-dev |
| 04:29 |
|
proller joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:45 |
|
v-rob joined #minetest-dev |
| 07:31 |
|
calcul0n joined #minetest-dev |
| 08:19 |
|
calculon joined #minetest-dev |
| 10:19 |
|
calcul0n_ joined #minetest-dev |
| 10:22 |
|
YuGiOhJCJ joined #minetest-dev |
| 11:11 |
|
appguru joined #minetest-dev |
| 12:17 |
|
proller joined #minetest-dev |
| 13:03 |
|
proller joined #minetest-dev |
| 13:45 |
|
proller joined #minetest-dev |
| 14:07 |
|
Lupercus joined #minetest-dev |
| 14:08 |
|
calcul0n joined #minetest-dev |
| 15:06 |
|
appguru joined #minetest-dev |
| 16:30 |
|
calculon joined #minetest-dev |
| 16:34 |
|
calcul0n joined #minetest-dev |
| 16:51 |
|
SFENCE joined #minetest-dev |
| 16:58 |
|
SFENCE joined #minetest-dev |
| 17:05 |
|
SFENCE joined #minetest-dev |
| 17:23 |
|
SFENCE joined #minetest-dev |
| 17:48 |
|
SFENCE joined #minetest-dev |
| 17:56 |
|
ivanbu joined #minetest-dev |
| 18:56 |
|
appguru joined #minetest-dev |
| 19:03 |
|
v-rob joined #minetest-dev |
| 19:32 |
sfan5 |
if there are no complaints I'd like to merge #13092 this evening |
| 19:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/13092 -- Lua on each mapgen thread by sfan5 |
| 19:53 |
pgimeno |
just wow, looking forward to it |
| 19:56 |
pgimeno |
does it break backwards compat? also, is there a provision for inter-thread communication? |
| 19:56 |
pgimeno |
@sfan5 ^ |
| 19:57 |
sfan5 |
no and no |
| 19:58 |
pgimeno |
hm, the second "no" limits its use a bit; still, it's a great advance |
| 19:59 |
pgimeno |
love2d has "channels" for inter-thread communication, which serialize/deserialize Lua data for communication and are also able to pass love2d objects |
| 20:00 |
sfan5 |
the issue I always see with ipc is the following: what are you planning to do? any blocking work will stop the engine from functioning normally. |
| 20:00 |
pgimeno |
in a thread? |
| 20:00 |
pgimeno |
maybe threads want to talk between themselves |
| 20:01 |
sfan5 |
but you don't get to choose and spawn threads |
| 20:01 |
sfan5 |
you're only running work in callbacks inside engine threads |
| 20:02 |
pgimeno |
still, they may need info on e.g. parameters or stuff |
| 20:02 |
pgimeno |
it can also be non-blocking communication |
| 20:02 |
sfan5 |
btw there is a way to communicate Lua data from the mapgen thread back to the main thread |
| 20:03 |
sfan5 |
i can see why mods may need bidirectional communication but they way everything is set up right now you would basically be adding a huge footgun because it's so hard to use IPC correctly without impairing the engine |
| 20:05 |
pgimeno |
I think I see your point |
| 20:05 |
sfan5 |
of course this our "fault" because we only give mods single-purpose specialized ways to offload work and not just threading primitives |
| 20:08 |
|
SFENCE joined #minetest-dev |
| 20:09 |
celeron55_ |
there's a huge advantage to single threaded operation though. it simplifies everything, up until to the point where you want to run large computational workloads |
| 20:09 |
celeron55_ |
if e.g. every mod was ran in its own thread, any APIs provided by mods would have to be IPC based |
| 20:10 |
celeron55_ |
then you'd end up wanting to be able to make "header-style" mods that are ran in the same thread that they are called in |
| 20:11 |
celeron55_ |
even if the "standard" was a mod ran in its own thread |
| 20:12 |
celeron55_ |
then, if a mod running in its own thread would want to do bulk-ish node operations, it would have no chance whatsoever of doing it with the basic api calls, as each would involve an environment mutex of some kind |
| 20:12 |
celeron55_ |
you'd basically always have to use a voxelmanip-style thing or a serialized list of operations of some kind |
| 20:13 |
celeron55_ |
then you'd probably have async and sync versions of every api |
| 20:14 |
celeron55_ |
every thread would be fighting for the ownership of things, or alternatively nobody would own them and performance for accessing anything in the actual game would be unbearably bad |
| 20:23 |
Krock |
at least the mapgen can easily be parallelized because.. it already is on C++ |
| 20:24 |
Krock |
side |
| 20:24 |
celeron55_ |
and it makes a lot of sense anyway |
| 20:24 |
celeron55_ |
it's crazy that it takes only about a thousand lines to stretch that to lua |
| 20:24 |
celeron55_ |
usefully |
| 20:24 |
Krock |
for anything else I could see async + callback-based approaches to be more helpful for compute-intensive tasks that are working with their own data |
| 20:26 |
celeron55_ |
yeah any time you can copy a chunk of data, throw it to a self-sufficient task and then get something back sometime later, a thread makes a lot of sense |
| 20:34 |
|
SFENCE joined #minetest-dev |
| 21:16 |
pgimeno |
celeron55_> if e.g. every mod was ran in its own thread, any APIs provided by mods would have to be IPC based |
| 21:16 |
pgimeno |
that doesn't sound too wise; I'm thinking about allowing mods to create their own threads instead |
| 21:17 |
pgimeno |
not sure it'd be useful tbh |
| 21:26 |
sfan5 |
merging #13092, #14298 in 10m |
| 21:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/13092 -- Lua on each mapgen thread by sfan5 |
| 21:26 |
ShadowBot |
https://github.com/minetest/minetest/issues/14298 -- [no squash] Dynamic media improvements by sfan5 |
| 21:47 |
|
Desour joined #minetest-dev |
| 22:21 |
MTDiscord |
<exe_virus> Question on multi-threaded mapgen: in that PR did it affect current mapgen v7 or rivers or anything? Or is this mod-only for now and not built-in mapgens? |
| 22:21 |
sfan5 |
engine mapgen has always been multi-threaded |
| 22:24 |
MTDiscord |
<exe_virus> oh - interesting - it never blocked main? gotcha |
| 22:24 |
MTDiscord |
<exe_virus> curse you caverealms haha |
| 22:26 |
Desour |
awesome new mapgen feature ๐๐. and dynamic media improvement is also nice ๐ |
| 22:28 |
nrz_ |
Good job guys ! |
| 22:29 |
nrz_ |
I like lua callbacks per threads. It's the good way, and for maintenability ensure they never communicate together (there is no interest here) |
| 22:38 |
|
proller__ joined #minetest-dev |
| 23:03 |
|
appguru joined #minetest-dev |
| 23:06 |
MTDiscord |
<jordan4ibanez> Maybe you could have some kind of atomic, mutex, or rwlock/wrlock so they could? That would be crazy |
| 23:22 |
MTDiscord |
<exe_virus> Just not valuable I think. Even with dynamic mapgen stuff, you would just use message passing to let them know about the changes, you wouldn't need to know when they finished. It's like a traditional graphics GPU pipeline, one way |
| 23:32 |
|
panwolfram joined #minetest-dev |
