Time Nick Message 10:07 hecks Are there any obstacles to compiling irr with SDL already? 10:09 sfan5 irrlicht only supports sdl1 so we have to basically do it ourselves 10:09 hecks hmmm 10:09 sfan5 and it affects a lot of stuff (GL context setup, input, windowing, fullscreen, ...) that has to be ensured to still work/made work 10:10 hecks GL management is the reason I'm asking 10:10 sfan5 if you want a core context I think that's doable with the current stuff 10:10 hecks without SDL, I have possibly six platform dependent ways of calling GetProcAddress 10:10 hecks with SDL that would become just one 10:11 hecks check out COpenGLExtensionHandler.cpp:405 for an example of the procaddress mess 10:11 sfan5 add a wrapper in irrlicht? not like the code not already exists 10:11 hecks it exists but it's kinda scattered, I'm trying to make sense of it 10:12 hecks irr has several manually written GL loaders scattered across various GL drivers 10:13 hecks here are the changes I'm making to that: first, the loader will be generated from the contents of all relevant GL headers 10:13 hecks second, the loader and GL driver will be shared 10:14 sfan5 shared in what way 10:14 hecks shared across all platforms 10:14 hecks no more separate desktop and ES drivers 10:14 sfan5 ah 10:14 sfan5 yes that makes sense 10:15 hecks here's a sample output of my generator https://paste.uguu.se/?a2c52240a6a02d07#BsVSWe96cYUDJigLYDVMkLs34iqrT9tRSsntLFcVQoiX 10:15 hecks it basically just tries every possible matching vendor version of each procedure in existence 10:15 hecks in a specific order, based on a vendor priority list 10:15 hecks it only looks for vaguely "core" procedures, that is 10:15 sfan5 we'd check in the generated source right? 10:16 hecks yes 10:16 sfan5 good 10:16 hecks I don't think it makes any sense to check in the generator itself or make it a part of the build because 10:16 hecks OpenGL will not change 10:16 hecks and this is futureproof up to GL4.6 if we want to use these features 10:17 hecks it tries to load anything in GL core up to 4.6, or GLES; automatically aliasing core functions to ARB, EXT or vendor specific versions as fallback, if the signatures match 10:17 sfan5 just having the generator might be useful but I agree it should not run at build 10:17 hecks I wouldn't mind uploading it but there's a little problem.... 10:17 hecks it depends on a loose assortment of scripts on my computer =] 10:17 hecks I could unroll it to vanilla lua 5.1 code but it would be a bit of work 10:18 hecks so maybe I'll do that when it's done 10:18 hecks just in case the generator needs patching 10:18 hecks still, if this is done correctly, we will never actually have to run it again 10:19 sfan5 no gl4.7 features ever? ;) 10:20 hecks ;] they're pretty late with that 10:20 hecks I guess they could make bindless textures a core feature... 10:20 hecks but it seems that all the work is focused on vulkan 10:23 hecks okay so if we're not pulling in SDL just yet then I'm not considering it in the loader 10:24 sfan5 when we're switching to it throwing out weird platform-specific stuff will be easy 10:30 hecks do I have to support _IRR_COMPILE_WITH_SDL_DEVICE_ right now though? 10:30 sfan5 no 10:31 hecks cool 10:31 hecks that's a lot less trash in the code 11:26 nrz what is the objective with irrlmt ? drop all except what we use then bind SDL2 on it ? 11:57 MTDiscord I'd assume so? the far fetched goal is improving it and absorbing it into minetest 13:01 twoelk resistance is futile irrlicht will be assimilated 13:54 hecks do we support iOS? :o 13:54 hecks I'm looking through the irrlicht code for that and it doesn't seem to even have GL extension loading 13:55 MTDiscord nope, we don't >:) 13:56 hecks Jordach 13:56 hecks if anyone would care it's him 13:57 MTDiscord oh yeah 13:57 MTDiscord he actually seems to have gotten minetestserver to build on ios 13:58 hecks server is low hanging fruit 13:58 MTDiscord well yeah there's no graphical stuff to be done for a server build 13:59 hecks anyway uhhh I literally can't find any resources on how to get an arbitrary GL proc address on ios 13:59 hecks it's not using EGL, it's using this EAGL thing 13:59 hecks so I guess CEAGLManager::getProcAddress will return null until someone tells me how to do it 14:00 hecks or better yet I'll keep it unimplemented and let the compiler complain 14:00 celeron55 complainer 14:24 MTDiscord iOS does support GLES2 14:27 MTDiscord and 3 14:29 hecks yes but how do you get an extension proc address on that? 14:30 hecks I found a way to do it for OSX but that's just plain symbol lookup, does iOS even allow you to dynamically link like that? 14:32 sfan5 hmm good point 14:32 sfan5 I'm sure the APIs exist but they wouldn't approve an app with that into the app store 14:35 hecks if they hate portability it's their problem 14:35 MTDiscord the only thing iOS will complain loudly about is any attempt at executing outside of your paged memory addresses 14:35 MTDiscord system libraries may be excluded 14:36 hecks do you feel like poking around in the ios documentation for a way to load a GL symbol? 14:36 hecks the osx way is this 14:36 hecks https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_entrypts/opengl_entrypts.html 14:37 hecks also anyone on linux or bsd, can you dump the symbols in your libGL.so and paste them for me somewhere 14:39 hecks I need to know if extension symbols are exported where dlsym can see them, or whether glXGetProcAddress must be used for extensions 14:40 sfan5 why use dlsym at all? 14:41 hecks the question is actually 'why use glxgetprocaddress at all' 14:41 hecks dlsym would be more consistent if it worked for everything (just like the apple way of doing it) 14:41 hecks i just straight up don't know how it works though 14:41 MTDiscord ES doesn't support getprocaddress 14:41 hecks how does ES do extensions then 14:41 MTDiscord ES doesn't have extensions 14:41 hecks :DDD it does dude 14:42 sfan5 because that's the intended API? 14:42 sfan5 doing it some other way that happens to work is a good way to run into problems later 14:42 MTDiscord also hecks, https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglGetProcAddress.xhtml 14:42 hecks yes I know 14:42 hecks eglGetProcAddress is what irrlicht uses on android 14:43 hecks on ios it uses literally nothing, i don't know if it even works 14:43 MTDiscord well the multicrap variant should be using 14:43 MTDiscord that, as they're the same source code 14:43 hecks :DD 14:43 hecks they got an ios client? 14:44 MTDiscord yes 14:44 MTDiscord there's many unofficial minetest clients on ios under different names lol 14:44 MTDiscord it's also an ad ridden privacy invading piece of shit 14:44 hecks well I wonder if that actually loads extensions or if it just avoids any ext procedures 14:44 sfan5 hecks: it directly links to the symbols provided by OpenGLES.framework or whatever 14:45 sfan5 ctrl+f for "if defined" in COGLESExtensionHandler.h 14:45 celeron55 < hecks> also anyone on linux or bsd, can you dump the symbols in your libGL.so and paste them for me somewhere 14:45 celeron55 https://paste.centos.org/view/raw/c69336f0 14:46 celeron55 that's libGL.so.1.7.0 on 64-bit fedora 33 14:46 sfan5 ^ looks identical here 14:46 hecks it seems to export extensions in a dlsym visible way 14:46 hecks unlike on windows for example 14:47 hecks everything is visible up to really late GL 14:47 hecks 000000000004a560 T glDispatchCompute 14:47 hecks meanwhile on windows the symbols are *not* exported as part of the DLL, that's why I wanted to know, thanks 14:47 sfan5 the reason it exports every symbol under the sun is because it's just a wrapper itself https://github.com/NVIDIA/libglvnd 14:47 hecks technically it should be safe to just dlsym all of them on unix 14:48 hecks and not have to rely on glx because it's actually more precarious 14:48 hecks this is also what SDL falls back to on android 14:49 hecks on windows it's kinda stupid, you can wglGetProcAddress everything except a dozen GL 1.1 functions, you need to use winapi for those 14:49 hecks anyway for the sake of sanity i'm trying to wrangle all the possible GL versions purely in terms of function pointers 14:50 hecks that's why a one size fits all symbol retriever is preferrable 14:51 hecks I actually wonder though 14:51 hecks irrlicht does a lot of monkeying with glXGetProcAddress because of GLX versions 14:52 hecks but does anybody actually use GLX older than 1.4? 14:52 sfan5 ¯\_(ツ)_/¯ 14:52 hecks or rather 14:52 hecks is this something you can tell everyone to just upgrade 14:52 hecks or are you at the graphics vendor's mercy for it 14:54 hecks unless irrlicht is overly paranoid about this and glXGetProcAddressARB is fine to use on everything, let me check that paste again 14:54 hecks yeah actually you seem to have that 14:54 celeron55 well irrlicht is definitely designed for how it was 15 years ago 14:54 celeron55 the question is has it changed since then 14:54 hecks I don't think GL drivers ever delete anything actually 14:54 hecks so an ARB alias should continue working 14:56 hecks so I guess the glx manager will use that and then fall back to dlsym in case something breaks 15:03 MTDiscord hecks, https://developer.apple.com/library/archive/documentation/OpenGLES/Conceptual/OpenGLESHardwarePlatformGuide_iOS/OpenGLESPlatforms/OpenGLESPlatforms.html 15:04 hecks that's great but how do you link the extensions 15:05 hecks do they just expect you to use the header with prototypes? 15:05 MTDiscord glad you asked https://developer.apple.com/library/archive/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Introduction/Introduction.html 15:07 hecks well I don't see anything about that here 15:08 MTDiscord it'd be in there 15:08 hecks nope 15:08 hecks apple literally pretends that loading proc addresses isn't a thing that somebody might want to know about 15:09 hecks this EAGL thing does not provide anything resembling that 15:09 pgimeno also anyone on linux or bsd, can you dump the symbols in your libGL.so and paste them for me somewhere <-- nm: /usr/lib/libGL.so: no symbols 15:09 hecks huh :o 15:10 sfan5 you need nm -D 15:10 pgimeno ah k 15:10 sfan5 not very obvious admittedly 15:11 hecks instead of pasting you can just tell me whether glXGetProcAddressARB exists 15:11 pgimeno I got the same when dumping with objdump -x. Sec, pasting the nm -D output. 15:11 hecks as well as whether it's full of ARB and EXT functions 15:11 sfan5 I assume glXGetProcAddressARB would be in libGLX 15:11 pgimeno http://www.formauri.es/personal/pgimeno/pastes/libGL.so.txt 15:12 pgimeno yes, glXGetProcAddressARB is there 15:12 sfan5 or in there too apparently 15:12 hecks looks the same 15:14 hecks and I guess we only use the EGL manager for GLES so it can assume libGLESv2.so in its loader 15:14 hecks and otherwise look almost identical 15:15 hecks and now finally the wgl manager, that's my problem =] 15:15 pgimeno going AFK, I won't be responsive for some hours 16:41 hecks compiling MT with the new GL loader for the first time 16:42 MTDiscord ooh ? 16:43 hecks it's not gonna do anything interesting now except add a few miliseconds to video driver init time 16:44 MTDiscord If you need macOS core profile testing I’m available in two or more hours 16:44 hecks but if it doesn't crash during that, one can technically already start calling GL procedures from MT already 16:44 hecks don't worry, that's days away 16:44 hecks I also think the OSX loader will be the most reliable 16:45 hecks given that it only loads static symbols that are already there 16:47 hecks no crash :o 16:47 hecks if i'm in the menu that means it already works, gl driver already exists by then 16:48 hecks i guess i could dump some known proc addresses to warningstream as a test 17:16 hecks https://a.uguu.se/0mZGXs0dkocv_procs.png whoa :o 17:17 hecks okay so this is actually tangential to the GL driver cleanup 17:17 hecks I could technically proceed with materials with this alone, the loader was all I wanted 17:30 hecks as for the cleanup, the battle plan is to write a new OpenGLCoreVideoDriver against this loader, using the GLES2 driver as reference 17:32 hecks question: I now have a couple opengl headers in /scripts/ in the source tree, do we gitignore or commit them? 17:32 sfan5 in scripts? 17:32 sfan5 oh the generator 17:32 hecks yeah, alongside the binding generator script 17:32 sfan5 gitignore IMO 17:32 hecks okay 17:33 hecks it can't use the system GL headers cause it actually emits an amalgamation of both desktop core and ES headers 17:33 hecks you can still make it work in CI by cloning the khronos repo to obtain the headers 18:02 celeron55 anything that can be generated should always be generated, it makes no sense to put generated files in git 18:04 celeron55 and due to that any generator needs to be portable to the systems MT can be built on 18:05 celeron55 if that's not possible, then rather break the first rule than the second 18:06 celeron55 if this isn't common sense then maybe it should be added to some guideline document 18:06 celeron55 but don't edit the wikis now, i'm moving them 18:15 hecks I can unroll it to puc lua 5.1, just not now 18:17 hecks maybe after i confirm it doesn't accidentally summon cthulhu 18:18 hecks pfngl wgl'proc Cthulhu R'lyeh mgohp'enGL fhtagn...... 18:26 Krock sfan5: https://krock-works.uk.to/u/patches/0001-OpenAL-Free-buffers-on-quit.patch is this what you mentioned in #8977? 18:26 ShadowBot https://github.com/minetest/minetest/issues/8977 -- Suspected extreme memory consumption since MT 5.0.0 18:27 sfan5 I was under the impression the buffers itself weren't deleted either 18:27 sfan5 is that a free function or the destructor? is the sound manager ever destroyed between games? 18:28 Krock yes this is called for every world leave 18:28 sfan5 s/steam/stream/ 18:28 sfan5 LGTM otherwise 18:28 Krock however SoundManagerSingleton does persist over the entire client lifetime 18:29 Krock typo corrected and tested it a few times locally. seems to work just fine. will push this in 15 minutes. 18:42 celeron55 lol 18:42 celeron55 there's a lesson: if you aren't sure something is a regression, do not file it as one 18:42 celeron55 the most counterproductive thing ever 18:43 Krock at least it uncovered a few trivial memory leaks 18:43 Krock granted it's very vague and somewhat not helpful. just a reminder to look out for such leaks 18:45 Krock pushing