| Time |
Nick |
Message |
| 00:04 |
|
SFENCE joined #minetest-dev |
| 00:39 |
|
SFENCE joined #minetest-dev |
| 00:43 |
|
ShadowBot joined #minetest-dev |
| 00:59 |
|
SFENCE joined #minetest-dev |
| 01:17 |
|
SFENCE joined #minetest-dev |
| 01:36 |
|
SFENCE joined #minetest-dev |
| 02:07 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:10 |
|
SFENCE joined #minetest-dev |
| 02:44 |
|
SFENCE joined #minetest-dev |
| 03:03 |
|
SFENCE joined #minetest-dev |
| 03:40 |
|
SFENCE joined #minetest-dev |
| 03:55 |
|
SFENCE joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:14 |
|
SFENCE joined #minetest-dev |
| 04:47 |
|
SFENCE joined #minetest-dev |
| 04:56 |
|
SFENCE joined #minetest-dev |
| 05:21 |
|
cranez joined #minetest-dev |
| 05:32 |
|
SFENCE joined #minetest-dev |
| 05:50 |
|
SFENCE joined #minetest-dev |
| 05:55 |
|
SFENCE joined #minetest-dev |
| 06:17 |
|
SFENCE joined #minetest-dev |
| 06:36 |
|
SFENCE joined #minetest-dev |
| 06:54 |
|
SFENCE joined #minetest-dev |
| 07:17 |
|
SFENCE joined #minetest-dev |
| 07:35 |
|
SFENCE joined #minetest-dev |
| 07:55 |
|
SFENCE joined #minetest-dev |
| 08:16 |
|
SFENCE joined #minetest-dev |
| 08:22 |
|
Warr1024 joined #minetest-dev |
| 08:47 |
|
Warr1024 joined #minetest-dev |
| 09:00 |
|
SFENCE joined #minetest-dev |
| 09:18 |
|
SFENCE joined #minetest-dev |
| 09:35 |
|
SFENCE joined #minetest-dev |
| 09:59 |
|
SFENCE joined #minetest-dev |
| 10:18 |
|
SFENCE joined #minetest-dev |
| 10:32 |
sfan5 |
btw meshgen is on a separate thread, so that's not it |
| 10:33 |
sfan5 |
you could try something like renderdoc to debug the rendering side of that |
| 10:34 |
MTDiscord |
<nrz0> @ExeVirus check context switching and locking mechanism, we should loose some performance there. If we want to be blasing fast, it's not ez and it require a massive change client side to work on a message queue instead of many sync orders to rendering engine |
| 10:34 |
MTDiscord |
<nrz0> but it's close to rewrite the whole renderer |
| 10:34 |
MTDiscord |
<nrz0> maybe not renderer, mostly the client |
| 10:46 |
|
SFENCE joined #minetest-dev |
| 10:49 |
|
Pexin joined #minetest-dev |
| 10:56 |
|
SpaceManiac joined #minetest-dev |
| 11:18 |
|
SFENCE joined #minetest-dev |
| 11:30 |
MTDiscord |
<exe_virus> Yeah, not meshgen, though that is slow haha. No it's the entity mesh rendering, which does happen client side, and I believe on the client updateFrame. |
| 11:30 |
MTDiscord |
<exe_virus> And also: yeah I'm personally not going to pull off a rewrite, but I can see performance improvements in front of me, so I'll try to get those done |
| 11:31 |
MTDiscord |
<exe_virus> Specifically, the skinned mesh animation and skinning when you have a bunch of entities is like 30% of client side thread time |
| 11:31 |
MTDiscord |
<exe_virus> With another 20% being their collision math haha. |
| 11:33 |
MTDiscord |
<redundantcc> Did the wheel inventory make it into 5.9, if the future freeze isn't currently in effect it might be a good idea to add ability to freeze/disable the mouse rotation as a server side and client side function. |
| 11:33 |
MTDiscord |
<redundantcc> * feature freeze |
| 11:40 |
|
SFENCE joined #minetest-dev |
| 11:57 |
|
SFENCE joined #minetest-dev |
| 12:21 |
|
SFENCE joined #minetest-dev |
| 13:04 |
|
SFENCE joined #minetest-dev |
| 13:21 |
|
SFENCE joined #minetest-dev |
| 13:24 |
|
Desour joined #minetest-dev |
| 13:39 |
|
SFENCE joined #minetest-dev |
| 14:03 |
|
SFENCE joined #minetest-dev |
| 14:04 |
sfan5 |
we're already in feature freeze |
| 14:41 |
|
SFENCE joined #minetest-dev |
| 14:59 |
|
SFENCE joined #minetest-dev |
| 15:05 |
|
SFENCE joined #minetest-dev |
| 15:41 |
|
SFENCE joined #minetest-dev |
| 16:06 |
|
SFENCE joined #minetest-dev |
| 16:41 |
|
SFENCE joined #minetest-dev |
| 17:07 |
|
SFENCE joined #minetest-dev |
| 17:42 |
|
SFENCE joined #minetest-dev |
| 17:58 |
|
SFENCE joined #minetest-dev |
| 18:08 |
|
SFENCE joined #minetest-dev |
| 18:26 |
|
SFENCE joined #minetest-dev |
| 19:10 |
|
SFENCE joined #minetest-dev |
| 19:28 |
MTDiscord |
<exe_virus> I know this sounds like a mediocre idea, but: I've been diving through the rabbit hole of converting C/C++ libraries to pure Lua 5.1 long story short: not possible easily. But to luaJIT: that's already been done and working. The issue is it makes use of 'ffi' for handling u64->f64->u64 kinds of situations. Wondering how hard it would be for us to expose those data types to our luaJIT builds? Benefits: most C libraries now open |
| 19:28 |
MTDiscord |
up as an option for modders to use. Stuff like valid Markdown parsers, valid XML parsers, regex if they happen to hate patterns for some reason, some of the math libraries, etc. Thoughts? |
| 19:28 |
|
SFENCE joined #minetest-dev |
| 19:29 |
MTDiscord |
<ipeeonwomenbecauseithinkitsfunny> what does it have to do with minetest? you mean binding them in your own package? |
| 19:29 |
Krock |
unprotected FFI could allow to manipulate the server memory or maybe even execute machine code. Thus I don't think that's generally somewhat we'd want to give modders |
| 19:30 |
MTDiscord |
<warr1024> it'd have to be a mod trust thing, yeah |
| 19:31 |
MTDiscord |
<exe_virus> Well, in this case the ffi merely gives them the ability to create u32, double, float, directly. Nothing else ffi would be exposed |
| 19:31 |
Krock |
there's some more points to that: http://luajit.org/ext_ffi_semantics.html (thanks Mike Pall for this explanation) |
| 19:31 |
Krock |
(heading "No Hand-holding!") |
| 19:37 |
MTDiscord |
<exe_virus> As a corollary of the above, the FFI library is not safe for use by untrusted Lua code. If you're sandboxing untrusted Lua code, you definitely don't want to give this code access to the FFI library or to any cdata object (except 64 bit integers or complex numbers). Any properly engineered Lua sandbox needs to provide safety wrappers for many of the standard Lua library functions — similar wrappers need to be written for high-level |
| 19:37 |
MTDiscord |
operations on FFI data types, too. Interestingly, I think I only need u64 and doubles |
| 19:42 |
sfan5 |
it sounds like you want some very specific operation and not actually "luajit ffi" |
| 19:43 |
sfan5 |
but I don't understand what would be the point of exposing ffi types and nothing else |
| 19:45 |
|
SFENCE joined #minetest-dev |
| 19:46 |
MTDiscord |
<exe_virus> Purely for inspection of doubles. Sadly, pure Lua 5.1 doesn't have a way, even with bit op, to get at those bits |
| 19:47 |
MTDiscord |
<exe_virus> Mostly, I'm curious if this is even a route I should take us down and create an example PR for... It would be some decent work that could be spent improving performance instead, for example |
| 19:50 |
sfan5 |
out of all things C/C++ libraries do bitcasts are they only thing that's missing in Lua? |
| 19:51 |
MTDiscord |
<exe_virus> Yes, basically. Because the toolchain I've been working with goes c/c++ -> WASM 32 -> luaJIT with some ffi as outlined above. WASMs memory model allows us to pull it off in pure Lua. Of course that emulation is a lot |
| 20:03 |
|
SFENCE joined #minetest-dev |
| 20:33 |
MTDiscord |
<exe_virus> A lot slower* |
| 20:36 |
|
SFENCE joined #minetest-dev |
| 20:51 |
MTDiscord |
<ipeeonwomenbecauseithinkitsfunny> speaking off, ill work on porting more stuff after work tonight |
| 20:51 |
MTDiscord |
<ipeeonwomenbecauseithinkitsfunny> (given im not sleepy) |
| 21:15 |
|
SFENCE joined #minetest-dev |
| 21:52 |
|
SFENCE joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 22:46 |
|
SFENCE joined #minetest-dev |
| 23:04 |
|
Noisytoot joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:05 |
|
SFENCE joined #minetest-dev |
| 23:23 |
|
SFENCE joined #minetest-dev |
| 23:26 |
|
nore joined #minetest-dev |
| 23:41 |
|
SFENCE joined #minetest-dev |
