| 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 |
