Time  Nick      Message
00:11 Mantar    sfan: I think it's so mods can add nodes that existing walls will connect to
00:11 Mantar    at least that's what I'd use it for, I couldn't decipher much of what the guy was saying
09:00 sfan5     so you want something to connect to but not add it to group:wall, is what I'm gathering
09:52 MTDiscord <luatic> sfan5: basically yes. commented https://github.com/minetest/minetest_game/pull/3159#issuecomment-2464271156
10:05 grorp     merging #15385 in 5
10:05 ShadowBot https://github.com/minetest/minetest/issues/15385 -- Revert 2D texture filtering change by grorp
10:33 MTDiscord <jordan4ibanez> So would there be any objection with using Vulkan 1.2 for the driver?
10:34 MTDiscord <jordan4ibanez> I cross referenced gpus all the way back from early 2012 support it
10:41 sfan5     yes: who will write the code?
11:18 MTDiscord <jordan4ibanez> So no objections, very good
14:49 MTDiscord <herowl> Objection!
14:50 MTDiscord <herowl> I have a GPU that doesn't support it and I do use it.
14:50 MTDiscord <herowl> (:
15:30 MTDiscord <warr1024> Haha, Vulkan ... might as well drop X11 for Waylan, and drop IPv4 for IPv6.  Let's adopt all the technology that was supposed to be the future 10 years ago and is supposedly still the future now.
15:34 [         I also have a GPU that doesn't support it
15:38 [         Vulkan 1.2 isn't supported until skylake (or maybe broadwell?) and haswell is the last version to currently have free raminit
15:41 [MatrxMT] <epickh> When looking at the Wikipedia-page for OpenGL (https://en.wikipedia.org/wiki/OpenGL), it says that the successor is Vulkan, implying that OpenGL is (more or less) deprecated.
15:41 [MatrxMT] <epickh> The last new release of an OpenGl version (4.6) was 2017, that's 7 years ago.
15:41 [MatrxMT] <epickh> The last new release of an OpenGL version (4.6) was 2017, that's 7 years ago.
15:41 [         Anything that doesn't work with OpenGL 2.1 is problematic, as that's the last version supported by any RYF system (unless you count software rendering, which is usually too slow)
16:10 MTDiscord <jordan4ibanez> Skylake? If your GPU has a programmable pipeline, it has vulkan support. Now if the drivers have been written for your GPU is a different story
16:11 [         https://gitlab.freedesktop.org/mesa/mesa/-/issues/6008
16:12 MTDiscord <jordan4ibanez> Vulkan 1.2 is supported all the way back in Gtx 680 HD 7770 which came out in 2012
16:12 [         haswell has OpenGL 4.6 but vulkan support is incomplete and apparently cannot be complete due to hardware limitations
16:13 MTDiscord <jordan4ibanez> Also, there is a very shrimple answer to your concerns: Just like you don't use the software rendering option, you don't have to use vulkan
16:13 MTDiscord <jordan4ibanez> And if you do, wat
16:17 MTDiscord <jordan4ibanez> But basically, what I hear on this argument is, I can't have it so no one can
16:21 MTDiscord <warr1024> I also have a machine that doesn't do Vulkan, in case that wasn't already obvious.
16:21 MTDiscord <warr1024> "Just like you don't use the software rendering option" <- lol, but I do.
16:22 MTDiscord <warr1024> Adding Vulkan support doesn't sound like a problem, though, as long as it doesn't add extra maintenance work keeping it in sync with the OpenGL renderer ... but I bet it does, doesn't it?
16:23 MTDiscord <jordan4ibanez> No, the vulkan API is stabilized in 1.2
16:24 MTDiscord <jordan4ibanez> Can also run on Macs with MoltenVK installed
16:24 [         what advantage is there to having a vulkan driver?
16:27 MTDiscord <jordan4ibanez> Let's take a nice simple example, a Java program vs a C++ program. One is easier to set up and use, one is lower level and allows a lot less overhead
16:27 MTDiscord <jordan4ibanez> Vulkan is mapped closer to how the gpu actually works
16:29 MTDiscord <jordan4ibanez> Additionally, OpenGL will not be getting any further version updates as well, so it's like you just cut yourself off at C++ 98 because you're skeptical about C++ 11
16:29 MTDiscord <wsor4035> to be frank, the engine right now is trying to get to more modern opengl(es) currently, while dealing with the dumpsterfire that is irrlicht, and you want to throw vulkan on the pile? the only way that might somewhat make sense is to adopt something like bgfx for graphics
16:30 MTDiscord <jordan4ibanez> Of course I do, maybe you'd get more graphics devs to take the engine seriously instead of seeing people arguing over OpenGL 2.1 support which came out 18 years ago
16:31 MTDiscord <cscscscscscscscscscscscscscscscs> what features are You using out of vulkan
16:31 MTDiscord <cscscscscscscscscscscscscscscscs> j dont think minetest would ever need vulkan, culling on the gpu side might be nice, but we arent doing shit like compressing vertices to the gpu
16:32 MTDiscord <jordan4ibanez> That's not the only advantage lol. A lot less overhead, less need for magic global state, full control and understanding of what is happening where
16:33 MTDiscord <warr1024> Vulkan sounds like it could offer us a lot of advantage if we wanted to drop support for all pre-Vulkan hardware and then rearchitect our rendering stack around it.  Which we might someday want to do, but probably not soon.
16:33 MTDiscord <jordan4ibanez> You don't need to do that at all, you can just add it in
16:33 MTDiscord <cscscscscscscscscscscscscscscscs> STKart has a similar issue where it pulls out Vulkan to optimize a few things but still sucks at everything else. Optimizing the actual game would be nice before we over optimize the graphics pipeline
16:33 MTDiscord <cscscscscscscscscscscscscscscscs> Id want to see a move to BGFX or something like wgpu first, honestly
16:33 MTDiscord <jordan4ibanez> It's not like I'm removing OpenGL out of the engine, I am simply adding in a new driver
16:33 MTDiscord <cscscscscscscscscscscscscscscscs> before we ever get vulkan support
16:34 MTDiscord <cscscscscscscscscscscscscscscscs> i dont think its the greatest use of your time. Its appreciated, but its gonna be more work to carry when irrlicht gets axed out soon
16:34 MTDiscord <cscscscscscscscscscscscscscscscs> or slowly gets axed out
16:35 MTDiscord <jordan4ibanez> Well that's the cool part, it's portable. Axe irrlicht and you can simply rip the driver out and it can be rebuilt fairly easily
16:35 MTDiscord <cscscscscscscscscscscscscscscscs> i havent done anything vulkan in a long time; what state in particular are you ripping out?
16:35 Desour    if we still want to support opengl (which we have to), adding a vulkan backend would at this point just be wasted work, not only for implementing it, but also for maintainence (e.g. also think about all the old shader version we have). it won't magically make luanti faster. what are the concrete features you'd want to use?
16:35 MTDiscord <cscscscscscscscscscscscscscscscs> ^^ point im making
16:35 MTDiscord <cscscscscscscscscscscscscscscscs> thats why i want to know what features were snagging out of it
16:36 MTDiscord <cscscscscscscscscscscscscscscscs> vertex compression wont help and at worst could even make it slower in ways depending on how often its done
16:36 MTDiscord <jordan4ibanez> The entire API because drivers are more optimized for the Vulkan API
16:36 MTDiscord <cscscscscscscscscscscscscscscscs> not quite :/
16:36 Desour    but luanti is not optimized for vulkan api
16:37 MTDiscord <cscscscscscscscscscscscscscscscs> i think u should really take a look at supporting BGFX; minetest is going to need that especially for Metal support (as well as basic vulkan support)
16:37 MTDiscord <jordan4ibanez> That's quite easy, it's just a plug in. Listen, this has been some fun bike shedding, but until I have test units that confirm what you are saying this is an entire what if scneario
16:37 MTDiscord <jordan4ibanez> scenario*
16:37 MTDiscord <jordan4ibanez> If the system supports Metal, it supports vulkan through moltenvk
16:37 MTDiscord <cscscscscscscscscscscscscscscscs> This game's slow ass lua garbage needs to get fixed first lol
16:38 MTDiscord <cscscscscscscscscscscscscscscscs> and the 0.5x threading
16:38 Desour    if you want to improve the garbage collector, fork luajit
16:43 Desour    btw., I planned to try to implement a wgpu backend some day, just for fun, and to see how one would map luanti's/irrlicht's global state render calls to such an api. but I didn't get to it yet. (wgpu, because I think caring of the memory management and whatnot with vulkan is a waste of time, and for the future web)
16:43 MTDiscord <jordan4ibanez> You are going to run into the borrow checker over and over
16:44 grorp     A big part of the recent work on getting Irrlicht into a state that doesn't suck has been getting rid of / unifying video drivers, with the goal of having less code paths and combinations to worry about. Adding a whole new driver would be counter-productive in that regard. There's a lot that needs to be done on Irrlicht rendering code and APIs before implementing a Vulkan driver would be a reasonable use of anyone's
16:44 Desour    I meant the c/c++ api, not rewrite it in rust
16:44 Desour    btw, @jordan4ibanez: how far is your rust rewrite of luanti?
16:44 [         wgpu has the major issue of requiring opengl 3.3/es 3.0
16:46 MTDiscord <jordan4ibanez> I gave up when I got sick of the borrow checker but here is it running with the vulkan backend using instancing and streaming color data https://youtu.be/bx5qqFdn-Cc
16:47 MTDiscord <jordan4ibanez> This is using a custom GLTF loader re-tooled from an existing project that was doing really weird stuff
16:50 Desour    :eyes: no meshgen yet?
16:50 MTDiscord <jordan4ibanez> Absolutely not, I probably will never use rust again
17:21 MTDiscord <cscscscscscscscscscscscscscscscs> @jumanji i think i support your decision to support Vulkan, but just dont be surprised if it takes months to get merged in. Really i think there should be a focus on improvements on the opengl side...
17:21 MTDiscord <cscscscscscscscscscscscscscscscs> im not even sure how youd be taking advantage of new Vulkan apis through the irrlicht api
17:21 MTDiscord <jordan4ibanez> I don't really care honestly as long as the code exists
17:22 MTDiscord <cscscscscscscscscscscscscscscscs> Justifiable: Have fun :)
18:14 MTDiscord <herowl> @jumanji I object to using Vulkan for the driver.
18:15 MTDiscord <herowl> I don't object to Vulkan being done alongside and being the target to switch to one day, because frankly OGL is a black box in the end, and VK is slightly less black-boxey.
18:23 MTDiscord <cscscscscscscscscscscscscscscscs> vulkan is genuinely for people making skyrim like open world games where they genuinely push the gpu to the limit
18:23 MTDiscord <cscscscscscscscscscscscscscscscs> not even kidding, that is half its justification besides being "prettier"
18:25 MTDiscord <herowl> Vulkan is for game engines.
18:25 MTDiscord <cscscscscscscscscscscscscscscscs> Certainly
18:25 MTDiscord <herowl> If Luanti is to be an engine and not an outdated one, it must support it.
18:25 MTDiscord <cscscscscscscscscscscscscscscscs> i think it's fine being in there, but we aren't even pushing it's features with the current abstraction of Irrlicht anyway
18:26 MTDiscord <herowl> Meh, features are shader model
18:26 MTDiscord <herowl> Vulkan and OGL4.6 are equal in that matter, mostly
18:26 MTDiscord <jordan4ibanez> Why do you need to use a bunch of features or specialties to use vulkan lol
18:27 MTDiscord <cscscscscscscscscscscscscscscscs> i think there is a thing that lets you put vertices in their own memory so we can occlude chunks
18:27 MTDiscord <jordan4ibanez> The way the engine is written, a driver is just another class you plop in
18:27 MTDiscord <herowl> Vulkan is for pipeline customization, and I personally wonder...
18:27 MTDiscord <cscscscscscscscscscscscscscscscs> typically you do this on the cpu side
18:27 MTDiscord <cscscscscscscscscscscscscscscscs> vulkan should allow this to be on the gpu side too
18:27 MTDiscord <jordan4ibanez> One step at a time
18:28 MTDiscord <cscscscscscscscscscscscscscscscs> You can also compress vertices over the cpu pipeline, which could be very useful when rendering a shit ton of chunks
18:29 MTDiscord <cscscscscscscscscscscscscscscscs> there are benefits, but we should really focus on optimizing the opengl too
18:29 MTDiscord <herowl> Well, the issue remaining is that it is called in a specific way, with a specific internal API. You need to make the API compatible with ancient crap at first, and then keep updating it as that is axed.
18:29 MTDiscord <jordan4ibanez> Yes, that's very straight forward
18:29 MTDiscord <cscscscscscscscscscscscscscscscs> even BGFX doesnt push vulkan to the limit
18:29 MTDiscord <herowl> We should focus on improving the way we are calling any of those.
18:30 MTDiscord <jordan4ibanez> Well the people that maintain the opengl driver can do that
18:30 MTDiscord <jordan4ibanez> Drivers*
18:30 MTDiscord <cscscscscscscscscscscscscscscscs> bgfx would probably be preferable over our current opengl stuff
18:31 MTDiscord <herowl> I'm not convinced
18:31 MTDiscord <cscscscscscscscscscscscscscscscs> neither am I lol
18:31 MTDiscord <cscscscscscscscscscscscscscscscs> ill have to convince myself
18:33 MTDiscord <cscscscscscscscscscscscscscscscs> but im saying it could eliminate the opengl code as well as provide opengl es support and many other cool things
18:33 MTDiscord <herowl> Would if be preferable to have if right now, here and done? Yes. Would it be preferable to spend a lot of time to work on it, instead of improving what we already have? Not so sure
18:33 MTDiscord <cscscscscscscscscscscscscscscscs> im implying that using bgfx's opengl implementation might actually be better than ours
18:34 MTDiscord <cscscscscscscscscscscscscscscscs> it should be 1:1 essentially
18:34 MTDiscord <cscscscscscscscscscscscscscscscs> we kill 6 birds with 1 stone
18:35 MTDiscord <cscscscscscscscscscscscscscscscs> but i still support a native vulkan implementation over that too
18:36 MTDiscord <cscscscscscscscscscscscscscscscs> i would just like bgfx to handle directX, metal (probably more stable than vkmetal or whatever?), webassembly, and such
18:37 MTDiscord <cscscscscscscscscscscscscscscscs> because if we push vulkan to the limits, we are to expect bugs
18:42 MTDiscord <jordan4ibanez> You're going to get a lot more bugs with an api abstraction layer
18:43 MTDiscord <warr1024> Y'all are talking more than the dev IRC channel typically seems to prefer.  Given that this seems to be all between discord users now, maybe move it to the engine channel and leave this channel a bit quieter unless you reach a conclusion or something.
18:44 [         does that exist on IRC?
18:44 MTDiscord <cscscscscscscscscscscscscscscscs> yeah i dont really like how we do that anyway
18:45 MTDiscord <cscscscscscscscscscscscscscscscs> seems exclusive
18:45 MTDiscord <warr1024> The point is to move it off of IRC to make IRC less noisy.  Alternatively, there's the regular minetest IRC channel that tolerates more noise.
18:47 MTDiscord <cscscscscscscscscscscscscscscscs> ok i see ur point, but moving to discord directly.. my point still stands. i want the irc people to chime in too sometimes :)
18:48 MTDiscord <warr1024> Try #minetest-irc then.
18:48 sfan5     if you wan opinion then discussing vulkan is a waste of time
18:48 sfan5     +t
18:49 Warr1024  ...and of course the link gets translated to the discord channel name on the IRC side, not the IRC channel name
18:49 [         I'm assuming that's #minetest
18:50 MTDiscord <warr1024> The discord-side names are just all consistently suffixed with -irc so it's not too hard to figure out 😄
18:50 MTDiscord <cscscscscscscscscscscscscscscscs> sfan5 yeah I'm kinda getting that too
18:50 MTDiscord <jordan4ibanez> So don't bother with it then
18:51 MTDiscord <jordan4ibanez> (?) I forgot my question mark
19:09 MTDiscord <luatic> I agree with sfan5. OpenGL is far from being the limiting factor. The limiting factor is a massive legacy codebase, especially that of Irrlicht when it comes to rendering. Before that is in a decent state, there is no point in even thinking about doing anything Vulkan.
19:11 MTDiscord <luatic> To name just one example of many: Skeletal animations are barely held together by duct tape currently, and aren't even done on the GPU. My refactoring & fixing PR for that one - not even considering putting this on the GPU yet - already comes out to something like a +300 -1000 diff, and with how everything is structured it isn't trivial to check that nothing is being broken.
19:26 grorp     merging #15396 in 15 min
19:26 ShadowBot https://github.com/minetest/minetest/issues/15396 -- [no sq] Fix ECF_D32 support in ogles2 video driver by grorp
20:06 MTDiscord <cscscscscscscscscscscscscscscscs> yeah, thats kinda the point i was making with wanting to ditch our old gl backend anyway
20:06 MTDiscord <cscscscscscscscscscscscscscscscs> it might not help regardless, but it could possibly eliminate any bugs with bad behavior
20:07 MTDiscord <cscscscscscscscscscscscscscscscs> vulkan is low priority, very low, so low in fact its not even on the table
20:42 sfan5     okay so we have the collision regression still in the milestone
20:43 sfan5     and the CAO color regression, which has a potential easy fix but no PR yet
20:43 sfan5     then the xcode stuff which nobody has looked at yet
20:47 sfan5     oh and also we still need to merge translations before release
20:51 grorp     and credits
20:52 sfan5     ah yes
20:57 grorp     sfan5: I'm thinking considering how minor the commits in #15399 are, they're probably better squashed even if not entirely related. Do you have an opinion on that?
20:57 ShadowBot https://github.com/minetest/minetest/issues/15399 -- [no sq] Two trivial rendering code fixes by grorp
20:59 sfan5     squashing is fine
21:00 grorp     ok