Minetest logo

IRC log for #minetest-dev, 2021-08-03

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:22 specing_ joined #minetest-dev
00:33 freshreplicant[m joined #minetest-dev
00:43 wsor4035 joined #minetest-dev
00:43 LW joined #minetest-dev
05:06 clavii joined #minetest-dev
05:06 ShadowNinja joined #minetest-dev
05:07 rubenwardy joined #minetest-dev
05:08 m42uko joined #minetest-dev
05:44 clavii joined #minetest-dev
09:29 Fixer joined #minetest-dev
09:37 Kimapr joined #minetest-dev
09:57 hecks joined #minetest-dev
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 calcul0n_ joined #minetest-dev
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 entuland joined #minetest-dev
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
10:33 longerstaff13 joined #minetest-dev
11:26 nrz what is the objective with irrlmt ? drop all except what we use then bind SDL2 on it ?
11:57 MTDiscord <Sublayer plank> I'd assume so? the far fetched goal is improving it and absorbing it into minetest
12:21 specing_ joined #minetest-dev
12:22 olliy1or joined #minetest-dev
12:39 twoelk joined #minetest-dev
12:58 calcul0n__ joined #minetest-dev
13:01 twoelk resistance is futile irrlicht will be assimilated
13:43 Taoki joined #minetest-dev
13:45 longerstaff13 joined #minetest-dev
13:53 hecks joined #minetest-dev
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 <Sublayer plank> nope, we don't >:)
13:56 hecks Jordach
13:56 hecks if anyone would care it's him
13:57 MTDiscord <Sublayer plank> oh yeah
13:57 MTDiscord <Sublayer plank> he actually seems to have gotten minetestserver to build on ios
13:58 hecks server is low hanging fruit
13:58 MTDiscord <Sublayer plank> 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:10 Guest77 joined #minetest-dev
14:24 MTDiscord <Jordach> iOS does support GLES2
14:27 MTDiscord <Jordach> 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 <Jordach> the only thing iOS will complain loudly about is any attempt at executing outside of your paged memory addresses
14:35 MTDiscord <Jordach> 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 <Jordach> ES doesn't support getprocaddress
14:41 hecks how does ES do extensions then
14:41 MTDiscord <Jordach> 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 <Jordach> 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 <Jordach> well the multicrap variant should be using
14:43 MTDiscord <Jordach> that, as they're the same source code
14:43 hecks :DD
14:43 hecks they got an ios client?
14:44 MTDiscord <Jordach> yes
14:44 MTDiscord <MNH48> there's many unofficial minetest clients on ios under different names lol
14:44 MTDiscord <Jordach> 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 <Jordach> 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 <Jordach> 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 <Jordach> 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 <hecks> 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
15:40 Extex joined #minetest-dev
15:47 Kimapr1 joined #minetest-dev
16:41 hecks compiling MT with the new GL loader for the first time
16:42 MTDiscord <Sublayer plank> 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 <Jordach> 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 LW joined #minetest-dev
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:38 twoelk joined #minetest-dev
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
19:39 Fixer_ joined #minetest-dev
19:54 Extex joined #minetest-dev
20:30 olliy joined #minetest-dev
21:47 olliy1or joined #minetest-dev
22:47 olliy joined #minetest-dev
23:40 AliasAlreadyTake joined #minetest-dev
23:50 olliy joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext