Time Nick Message 06:57 MTDiscord [off] what's this [off] thing about? does it prevent the message from appearing in the logs or what? 07:02 MTDiscord seems like it 07:03 BuckarooBanzai Yes: https://irc.minetest.net/minetest-dev/2021-08-04#i_5856620 07:03 MTDiscord doesn't work for discord bridged users so it seems to need to be at the very beginning of the message 07:12 MTDiscord makes sense, discord users are already logged by discord 07:12 MTDiscord actually wait, irc is logged here too 15:36 hecks #irrlicht/52 15:36 hecks #irr/52 15:36 hecks irr#52 ? 15:36 ShadowBot https://github.com/minetest/irrlicht/issues/52 -- Implement a GL procedure loader by hecktest 15:37 hecks would it be that hard to get CI to use mesa so that we can kill the null device instead of having to support it here? 15:41 sfan5 it already does that (too) 15:41 sfan5 however I think being able to run the client without rendering is useful 15:41 hecks supporting that may become very difficult though 15:42 hecks at least in this way 15:42 hecks it can be done by just not calling the renderer 15:43 hecks the alternative is to write no-op shims for every GL function... 15:43 sfan5 hm 15:43 hecks and it does not suffice to generate them based on signature because a GL driver must guarantee a few things 15:44 hecks like incrementing handle IDs 15:44 sfan5 just not calling the renderer is doable 15:44 sfan5 but I worry about creating scenenodes or whatever else the client also does 15:44 ShadowNinja Why use a custom loader generator instead if something like GLAD? 15:45 hecks because I had a look at GLAD and it doesn't seem to do what I need 15:45 ShadowNinja What is it missing? 15:46 hecks that's not even the right question 15:46 hecks it's just not this kind of loader 15:47 hecks I don't think GLAD can generate a hybrid loader for both GL core and GLES 15:47 sfan5 what about GLEW 15:48 hecks glew is ancient, does it even support GLES? 15:48 sfan5 I don't know :D 15:48 hecks why do y'all think I didn't have a look at all the available wranglers before doing this 15:49 hecks back to the null device, there's another problem 15:49 hecks you'd also have to avoid creating meshes and textures 15:50 sfan5 is it feasible to make a dummy implementation just for that? 15:50 hecks of what though 15:51 hecks you either make no-op shims of GL procedures for it, or you pollute the rest of the code with special cases for the null driver 15:51 sfan5 the former I mean 15:51 hecks do you feel like writing them by hand? 15:51 hecks they cannot be safely generated 15:52 sfan5 perhaps 15:52 hecks at least that wouldn't pollute client code 15:52 sfan5 I don't know the extent of it, if it's just a few methods it should be fine 15:52 hecks but you literally are writing a null OpenGL driver then 15:53 hecks it may be possible to scan the function signature to generate *some* of the functions 15:53 hecks if it's a void that takes no pointers, it's safe to shim with an empty body 15:54 hecks but every GLES2 function that takes a pointer needs case by case examination 15:54 hecks beyond GLES2 we don't need to care 15:54 hecks we would just report every extension as unsupported on the null device 15:54 hecks now GLES2/gl2.h is not long 15:56 hecks it has 142 procedures 15:56 sfan5 I'm thinking of something comparable to "implement glGenTextures to return unique numbers" in complexity 15:57 sfan5 hoping that we can get away with it 15:57 sfan5 rendering should still be skipped for the null driver 15:58 hecks yeah let me run the numbers 15:58 hecks 72 "unsafe" functions based on the above heuristics 15:59 hecks not all of them return things however 15:59 hecks let me prune this list further 15:59 hecks I might be able to hardcode a dozen shims into the generator 15:59 hecks and template the rest 16:04 hecks okay but then we get to the actually unsafe functions 16:04 hecks getters mostly 16:05 hecks glGetUniformfv glIsEnabled glIsTexture glIsProgram etc 16:05 hecks *technically* they shouldn't be used in the first place 16:05 hecks I will never use them myself but I cannot promise you that some genius won't try in the future 16:05 sfan5 glIsTexture sounds like a terrible hack 16:06 hecks they could technically be blacklisted in the loader itself 16:06 hecks and not even exposed 16:06 sfan5 could mark the symbol as deprecated 16:06 hecks I could literally just not provide the symbol and that would be the best 16:07 hecks even IsEnabled is sketchy 16:07 hecks a GL program should generally try to keep track of state by itself to minimize chatter 16:07 hecks asking the GL driver for anything is poor form 16:08 hecks it's not like the GL driver is allowed to change state without being asked 16:08 hecks and initial state is also documented and consistent 16:08 hecks alternatively, return false on IsEnabled in the null driver 16:09 hecks glGetUniformLocation - now this one *is* necessary and important 16:09 hecks and this is where things start getting really hairy and ugly 16:10 hecks you see, uniform layout queries are something that my material code relies on for memory management... 16:12 sfan5 return a hash of the name? the numeric value doesn't carry meaning, does it? 16:13 sfan5 >The array element operator "[]" and the structure field operator "." may be used in name in order to select elements within an array or fields within a structure. 16:13 sfan5 hm 16:20 hecks I straight up can't tell you ahead of time which GL state we actually must implement and to what degree to avoid crashes 16:21 hecks basically any time someone uses data from OpenGL in the engine code to do things, a null implementation could crash things if not written as carefully as an actual OpenGL implementation 16:23 hecks here's my quick and dirty assessment of the importance of GL functions known to return data 16:23 hecks https://paste.uguu.se/?b1045832a0e9d3b3#9S2e1ytSyFXFijndyKA5wLJTAKemmStmhT9Bd2uoHY9m 16:23 hecks but I do not guarantee that this is in any way correct or accurate 16:23 ShadowNinja hecks: glad can generate separate gladLoadGLLoader, gladLoadGLES1Loader, and gladLoadGLES2Loader functions if you ask for those three APIs. You can define GLAD_GLAPI_EXPORT_BUILD to get to to do a dllexport on Windows. I'd just rather use something standard if possible. I looked into loaders a while back and settled on glad, some of the others didn't support Wayland or Windows properly. 16:24 hecks you're not the one who will actually have to use this, though :] 16:25 hecks oh and see, glad wouldn't take care of our null driver issue 16:25 ShadowNinja Fair enough. 16:28 hecks I think that having our own generator will be very convenient 16:29 ShadowNinja Yeah, that's a separate issue. Trying to handle that through the loader layer seems pretty ugly though. I'd either use a proper no-op driver (maybe some mesa thing) or handle it at a higher level as separate "null" graphics API, just like engines normally have some subset of GL/GLES/D3D/Vulkan/Metal/NVAPI/etc. 16:29 hecks I suggested that we ditch the null driver and just use mesa in CI 16:29 hecks but sfan wants headless clients, I'm not sure what for 16:30 hecks problem is that I do not really want to pollute the code with awareness of anything other than OpenGL 16:32 hecks consider that we do not have the manpower to maintain something this byzantine 16:32 hecks and the abstractions currently in place are largely a fiction, this is an OpenGL engine 16:34 hecks the fact that all rendering functions have to go through IVideoDriver is actively hurting the quality and performance of our code 16:35 hecks even if IVideoDriver abstraction was reduced to only "some kind of GL", you'd basically be doing the same thing but with more manual writing 16:35 hecks more empty shims that you'd have to write instead of being able to generate at least 80% of them from the GL header 16:36 hecks emulating only a tiny subset of OpenGL or dropping the null driver entirely would both be an improvement over the status quo 16:37 celeron55 if it's not practically possible, then there will be no null driver 16:37 hecks I'll try to at least have a good look at the issue before giving up 16:38 hecks the required state etc. is all nicely documented and in practice it shouldn't be difficult to write a tiny portion of a GL driver 16:38 hecks or steal it from mesa even 16:39 hecks it seems that most of the precarious state is concentrated around shaders, ironically 16:39 Pexin would a headless client be used for, like, usermade bots on servers that allow such things? 16:40 hecks maybe just failing to compile all shaders will be enough 16:40 hecks then shader code should not even get to the reflection and memory management part 16:40 celeron55 Pexin: mostly just testing headlessly that all the C++ code runs ok 16:41 hecks you can run tests with mesa though 16:41 hecks with a 1x1 window or something 16:41 Pexin or logging in through ssh/screen just to use ingame chat without having to render 16:42 celeron55 well in theory there could be some weird client mode like that 16:42 celeron55 but we don't have that currently 16:42 Pexin oh i know, not currently 16:42 MTDiscord Isnt that literally what the server terminal is? 16:42 celeron55 and you could have a much thinner client for that 16:42 celeron55 no need to run all the physics and stuff 16:43 hecks doesn't sound like something worth maintaining a null driver or polluting the client code with 16:43 hecks imagine servers having to deal with these sorts of broken clients 16:43 celeron55 yeah, definitely not 16:43 hecks if it doesn't run movement physics or collision, it's basically like a cheat client 16:43 celeron55 it would be a specific mode in the client that also tells to the server it's a non-gameplay client 16:43 hecks that sounds like a job for a separate program actually 16:43 celeron55 basically a moderator tool 16:44 hecks this is why i threw out the idea of a libMT earlier 16:44 hecks if we had a libmt with the network protocol, writing such things would become a lot easier 16:44 celeron55 well the network protocol is very static and compatible, just copy the protocol files and you're golden 16:45 hecks I suppose so 16:45 hecks though you'd have to maintain it as the protocol is updated 16:45 celeron55 well just copy the files and... so on 16:45 celeron55 we'll see 16:45 MTDiscord Do we really have a need for connecting custom clients to MT for admin purposes when we already have server-side modding and chat bridges? It seems like the needs are already covered pretty decently. 16:45 celeron55 currently there aren't many C++ programs using the protocol 16:46 celeron55 anyway, the end result of all this is the same: no need for a null video driver really 16:46 hecks I think ssh moderation is better done as a server side feature 16:46 hecks you should be able to cook up something in lua that lets you ssh to the server machine and moderate from there 16:46 hecks I plan on writing just that for myself 16:47 hecks cause ironically it'll be more secure than logging into the game as admin 16:47 celeron55 you could even host a web browser interface from lua 16:47 celeron55 for a really fancy experience 16:47 hecks yup, i could have a http dashboard 16:47 MTDiscord I already use szutil_consocket for moderation over ssh. All we really need is #10120 to make configuring it not a pain in the ass. 16:47 ShadowBot https://github.com/minetest/minetest/issues/10120 -- First-class support for luasockets (if installed) in mod API 16:47 hecks though ssh just works, you can't botch security with that 16:48 hecks and i can make it fancy enough with term escapes, don't you worry about that 16:49 celeron55 for serious work often text mode UIs are still used, even in stuff you pay lots of money for 16:50 celeron55 it's just the consumer crap that requires fancy graphics 16:56 celeron55 this is too fast, i can't read anything 17:25 hecks okay, who's willing to test my PR on linux and help me integrate it properly into the build system? 17:26 sfan5 the usecase for the null driver is CI/automated testing btw 17:26 sfan5 you can obviously make a much thinner headless client but that's not the point of testing 17:26 hecks can't we use mesa in CI? 17:27 sfan5 we could 17:27 sfan5 I haven't come up with a good reason I don't like that yet 17:27 hecks that would allow tests to cover a lot more 17:27 sfan5 so maybe we'll end up with it 17:28 hecks it would be valuable to have some tests for shaders 17:28 sfan5 re build system: didn't we want to commit the generated file? 17:28 hecks uhhhh someone convinced me otherwise and 17:28 hecks i cleaned up the script to work on vanilla lua 17:29 hecks it shouldn't be hard to find a copy of lua for any building machine because it's our dep anyway 17:29 sfan5 it's not but it's another thing you have to install 17:30 sfan5 it'll also make the build depend on external input (the khronos headers) 17:30 hecks I think it was c55 who wanted the artifacts ignored and not the script, check the logs 17:33 sfan5 >:( 17:36 hecks okay, what was i 17:36 hecks right so the headers are easily obtained from https://github.com/KhronosGroup/OpenGL-Registry 17:36 hecks it shouldn't be hard to fetch them in CI 17:37 hecks I'm fine doing it either way really, commit either the script or the artifacts 17:37 hecks I'll let you guys argue about it 17:37 hecks it's not like anyone else is actually going to touch the script 17:38 sfan5 as you know I'm for comitting the artifacts 17:38 sfan5 +m 17:38 sfan5 there's not much point making people generate bit-identical files themselves when we could just commit it 17:39 hecks it's a little cleaner to generate them on build 17:41 hecks anyway the script is cleaned up so both can be committed 17:49 pgimeno I just hope they are not necessary for normal builds 17:51 pgimeno I hate build systems that require an internet connection 17:55 celeron55 just commit the artifacts 17:56 celeron55 i said if it's too much trouble to generate them, just include them 18:00 hecks alright 18:00 hecks it's not a ton of trouble but I understand 18:00 hecks also it'll make my job easier right now because CI will work again 18:04 rubenwardy I don't like to commit generated files, it's redundant 18:14 hecks I'll do it at least temporarily because it makes testing easier 18:14 celeron55 the problem isn't CI, it's end user builds 18:15 hecks right 18:15 celeron55 those cannot be made very complex, it's important to have them 18:15 hecks for now this is irrlicht and few people build that, but if we are to absorb this back into MT 18:15 hecks i mean it's not a *huge* deal to require an installation of lua on the machine, most people will have that 18:15 celeron55 well everyone building MT has to build it too 18:16 celeron55 if the opengl registry can be installed on common linux distros from the package manager, then it's possible to include it as a build dependency 18:16 celeron55 otherwise, it's too much 18:17 hecks_ is there no clean way to weave this into cmake? 18:17 hecks_ ship with the headers and have cmake run the script 18:18 celeron55 scripts are a bit iffy when we need to be able to build on both unix-style things and native windows (visual studio) 18:18 rubenwardy I use cmake to do build steps 18:18 sfan5 cmake can do arbitrary build commands 18:18 rubenwardy To call python scripts 18:19 rubenwardy Although it can do anything 18:19 sfan5 who's gonna techsupport windows users into download some random lua.exe into their PATH to compile irrmt? 18:20 celeron55 we should be proud of minetest's ability to be built on both windows and linux by almost complete noobs if they try hard enough 18:20 celeron55 not actively try to get rid of that 18:20 celeron55 not many projects this size are capable of that 18:21 hecks_ technically I know how to set this up in VS too but fine, committed artifacts don't bother me too much 18:21 celeron55 it benefits us by bringing in more people who test unstable code, there's always a lack of those 18:25 hecks_ https://github.com/minetest/irrlicht/pull/52/checks?check_run_id=3255271064 now why would this coredump... 18:25 hecks_ is that even related to the PR 18:26 hecks_ right, i don't even touch the GLES driver yet 18:26 hecks_ it's probably not my fault =] 18:27 hecks_ linux-gl CI passes, anyone willing to go on an adventure? 18:27 sfan5 linux-gl doesn't run those 18:27 sfan5 I don't know why I didn't make it do that 18:27 hecks_ no no, this is a linux-gles fail 18:27 hecks_ linux-gl passed 18:28 sfan5 I'm saying linux-gl can't fail because it doesn't run the tests 18:28 hecks_ oh :] well but it compiles 18:30 sfan5 http://sprunge.us/yusmgB 18:31 celeron55 it's just using segfault as a shutdown signal :^) 18:31 hecks_ anyway anyone on linux or bsd who wants to help, please follow the testing instructions in irr#52 18:31 ShadowBot https://github.com/minetest/irrlicht/issues/52 -- Implement a GL procedure loader by hecktest 18:32 hecks_ now let's see why osx fails 18:33 hecks_ oh wow, the macos CI isn't actually in c++11 mode? 18:35 sfan5 for certain reasons some files are compiled as objective c++ on macos 18:37 sfan5 why not turn the class into a namespace? 18:47 hecks_ because :: hurts my wrists 18:48 hecks_ and I kind of intended for this to replace the "gl" wart and eventually GL_ in constants 18:48 hecks_ again :: would suck for this purpose 18:49 hecks_ oh and making it a namespace would mean that all of these pointers suddenly must be exported symbols in the DLL 18:49 hecks_ rather than just one struct 18:50 hecks_ it would bloat the DLL a bit at least on windows 18:51 sfan5 I wouldn't care about that but :: is a good reason not to 18:54 pgimeno how does one build with the irrlicht binaries in build/ ? 18:54 pgimeno https://termbin.com/5f2w 18:54 sfan5 point the prefix path to build 18:55 sfan5 ...is what I was told should work 18:55 pgimeno it doesn't for me 18:56 hecks_ here we go again! 18:57 pgimeno I removed one level of .. and now I get a different error: include could not find load file: 18:57 pgimeno ...irrlicht/build/IrrlichtMtTargets.cmake 18:57 sfan5 try absolute paths 18:57 pgimeno sigh 18:59 pgimeno do I have to do something with lib/irrlichtmt? 18:59 sfan5 no 18:59 pgimeno then I can't get it to work 18:59 pgimeno with an absolute path I get the same error as when removing one level of .. 19:00 hecks_ okay, it all compiles 19:00 sfan5 ask @josiah_wi 19:00 hecks_ Jordach help me test the GL loader on mac 19:07 pgimeno hecks: do your branches have #11287 in them? 19:07 ShadowBot https://github.com/minetest/minetest/issues/11287 -- Take advantage of IrrlichtMt target by JosiahWI 19:08 pgimeno hecks_: ^ 19:08 hecks_ uhhhh 19:09 sfan5 the other branch should also have irr#49 for this to work 19:09 ShadowBot https://github.com/minetest/irrlicht/issues/49 -- Export targets to build tree by JosiahWI 19:09 hecks_ let me just rebase everything 19:09 pgimeno k 19:09 pgimeno because even using . as the build dir fails to detect IrrMT 19:10 hecks_ irr PR rebased 19:11 hecks_ MT gl test branch should be up to date 19:13 pgimeno that worked 19:19 pgimeno hecks_: if creating a devtest work and entering it without problems means it worked, then it works for me on Linux 19:19 hecks_ what does the terminal say? 19:20 hecks_ it should spit out some pointers in warnings 19:21 pgimeno https://termbin.com/2ie3 19:21 hecks_ just out of curiosity, what's the card? 19:21 hecks_ the gpu 19:21 pgimeno nVidia 19:21 hecks_ chip series? 19:22 pgimeno GeForce 210 19:22 hecks_ interesting 19:23 pgimeno what is? 19:24 hecks_ it seems that on linux you can always get pointers to procedures even if the card doesn't support them 19:24 hecks_ your card should not be able to use DispatchCompute and GetTextureHandle 19:24 hecks_ and would probably crash if you tried 19:24 pgimeno is there any extension I can check for via glxinfo? 19:24 hecks_ just confirming that any usage of higher GL should be gated by the appropriate extension check 19:25 hecks_ DispatchCompute is arb_compute_shader (core in gl4) and GetTextureHandle is ARB_bindless_texture 19:25 hecks_ ARB_bindless_texture isn't supported until kepler 19:26 hecks_ okay so GLX confirmed to work 19:26 pgimeno no, neither of them is there 19:26 hecks_ I knew they aren't, yours is a GL3 card 19:26 pgimeno yes, 3.3 19:27 pgimeno but I've seen many weird things :) 19:27 hecks_ the difference is that GL on linux actually exports all the pointers in the .so and thus they can be loaded, even if they don't work 19:27 pgimeno maybe the procs are stubs or something like that? they do look like genuine valid pointers 19:28 hecks_ meanwhile on windows only GL1.1 functions are exported and the rest actually live in nvoglv64.dll or whatever it's called, in the driver 19:28 hecks_ that's why for example 19:28 hecks_ glEnable: 0x7fef5cbb3a0 19:28 hecks_ but 19:28 hecks_ glDispatchCompute: 0x48f6d80 19:28 hecks_ one is in the program's space, another seems really low and is probably in the driver 19:29 hecks_ then, glGetTextureHandle: 0x0 19:29 hecks_ because I have a fermi card and those don't have bindless texture 19:30 pgimeno you mean in Windows? 19:30 hecks_ yup 19:30 hecks_ in any case this means that it's not safe to null check the pointer for this 19:30 hecks_ I need to add an extension checker 19:31 hecks_ just the driver's extension string chopped into an std::unordered set 20:16 pgimeno are network packets authenticated? 20:22 sfan5 no