| 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 |
| 03:12 |
|
v-rob_ joined #minetest-dev |
| 04:31 |
|
SFENCE_arch joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:10 |
|
v-rob_ joined #minetest-dev |
| 06:29 |
|
SFENCE_arch joined #minetest-dev |
| 06:36 |
|
YuGiOhJCJ joined #minetest-dev |
| 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 joined #minetest-dev |
| 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:15 |
|
fluxionary joined #minetest-dev |
| 11:18 |
MTDiscord |
<jordan4ibanez> So no objections, very good |
| 11:25 |
|
grorp left #minetest-dev |
| 12:24 |
|
Farooq joined #minetest-dev |
| 12:26 |
|
SpaceManiac joined #minetest-dev |
| 13:15 |
|
Desour joined #minetest-dev |
| 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:32 |
|
v-rob_ joined #minetest-dev |
| 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) |
| 15:42 |
|
hwpplayer1 joined #minetest-dev |
| 16:06 |
|
SFENCE_arch joined #minetest-dev |
| 16:06 |
|
SFENCE joined #minetest-dev |
| 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:40 |
|
grorp joined #minetest-dev |
| 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:49 |
|
grorp joined #minetest-dev |
| 16:50 |
Desour |
:eyes: no meshgen yet? |
| 16:50 |
MTDiscord |
<jordan4ibanez> Absolutely not, I probably will never use rust again |
| 16:58 |
|
v-rob_ joined #minetest-dev |
| 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 :) |
| 17:28 |
|
Desour joined #minetest-dev |
| 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 |
|
v-rob_ joined #minetest-dev |
| 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:25 |
|
grorp joined #minetest-dev |
| 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 |
| 19:44 |
|
SFENCE joined #minetest-dev |
| 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:13 |
|
SFENCE joined #minetest-dev |
| 20:21 |
|
SFENCE joined #minetest-dev |
| 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:55 |
|
SFENCE joined #minetest-dev |
| 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 |
| 21:18 |
|
grorp left #minetest-dev |
| 21:27 |
|
SFENCE joined #minetest-dev |
| 22:04 |
|
SFENCE joined #minetest-dev |
| 22:22 |
|
SFENCE joined #minetest-dev |
| 22:40 |
|
SFENCE joined #minetest-dev |
| 22:59 |
|
SFENCE joined #minetest-dev |
| 23:22 |
|
SFENCE joined #minetest-dev |
| 23:32 |
|
panwolfram joined #minetest-dev |
| 23:57 |
|
SFENCE joined #minetest-dev |
