| Time |
Nick |
Message |
| 00:20 |
|
specing_ joined #minetest-dev |
| 01:29 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:48 |
|
olliy joined #minetest-dev |
| 06:03 |
|
Kimapr joined #minetest-dev |
| 06:57 |
MTDiscord |
<Kimapr> [off] what's this [off] thing about? does it prevent the message from appearing in the logs or what? |
| 07:02 |
MTDiscord |
<Sublayer plank> seems like it |
| 07:03 |
BuckarooBanzai |
Yes: https://irc.minetest.net/minetest-dev/2021-08-04#i_5856620 |
| 07:03 |
MTDiscord |
<Sublayer plank> doesn't work for discord bridged users so it seems to need to be at the very beginning of the message |
| 07:12 |
MTDiscord |
<Kimapr> makes sense, discord users are already logged by discord |
| 07:12 |
MTDiscord |
<Kimapr> actually wait, irc is logged here too |
| 09:07 |
|
entuland joined #minetest-dev |
| 10:01 |
|
tech_exorcist joined #minetest-dev |
| 10:05 |
|
calcul0n_ joined #minetest-dev |
| 11:03 |
|
YuGiOhJCJ joined #minetest-dev |
| 11:07 |
|
calcul0n__ joined #minetest-dev |
| 11:17 |
|
maximed joined #minetest-dev |
| 12:21 |
|
specing_ joined #minetest-dev |
| 13:50 |
|
Guest joined #minetest-dev |
| 14:10 |
|
tech_exorcist joined #minetest-dev |
| 14:46 |
|
Fixer joined #minetest-dev |
| 15:04 |
|
Guest joined #minetest-dev |
| 15:36 |
|
hecks joined #minetest-dev |
| 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 |
|
olliy joined #minetest-dev |
| 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:48 |
|
Extex joined #minetest-dev |
| 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 |
|
calcul0n joined #minetest-dev |
| 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 |
|
longerstaff13 joined #minetest-dev |
| 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 |
<GreenXenith> 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 |
<Warr1024> 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 |
<Warr1024> 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:35 |
|
Extex joined #minetest-dev |
| 17:36 |
|
hecks joined #minetest-dev |
| 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:48 |
|
entuland_ joined #minetest-dev |
| 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_ joined #minetest-dev |
| 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:19 |
|
Extex joined #minetest-dev |
| 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 |
|
twoelk joined #minetest-dev |
| 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:46 |
|
longerstaff13 joined #minetest-dev |
| 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:03 |
|
Kimapr joined #minetest-dev |
| 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 |
| 19:48 |
|
Extex joined #minetest-dev |
| 20:16 |
pgimeno |
are network packets authenticated? |
| 20:22 |
sfan5 |
no |
| 23:38 |
|
Alias2 joined #minetest-dev |
