| Time |
Nick |
Message |
| 00:57 |
|
proller joined #minetest-dev |
| 01:16 |
|
Alias joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:35 |
|
calcul0n joined #minetest-dev |
| 08:24 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:18 |
|
Fixer joined #minetest-dev |
| 10:06 |
|
HuguesRoss joined #minetest-dev |
| 10:09 |
|
proller joined #minetest-dev |
| 10:59 |
|
proller joined #minetest-dev |
| 11:09 |
|
appguru joined #minetest-dev |
| 11:16 |
|
Taoki joined #minetest-dev |
| 11:20 |
|
jojje joined #minetest-dev |
| 12:27 |
|
cranezhou joined #minetest-dev |
| 14:34 |
paradust |
Is it expected that many shaders (e.g. object_shader/opengl_fragment.glsl) don't work with gles under #version 100 ? |
| 14:35 |
paradust |
*using #version 100, rather |
| 14:37 |
paradust |
Sadly WebGL supports only versions 100 and 300 es. Nothing in between, no compatibility profiles. |
| 14:37 |
paradust |
So the next question becomes, has anyone made any attempt to bring the shaders/pipeline up to 300 es. |
| 14:44 |
paradust |
Although it would probably be easier to back it down to 100, since it seems to be using features only from version 120 |
| 15:25 |
sfan5 |
I was under the impression that only GLESv2 supports shaders |
| 15:25 |
sfan5 |
maybe WebGL is different |
| 15:36 |
paradust |
yea. The version numbers are a mess. WebGL1 is GLESv2, which supports GLSL ES 1.00 (i.e. version #100). WebGL2 is GLESv3 which supports GLSL ES 3.00 (#version 300 es) |
| 15:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/100 -- Unexpected uses of transparency lead to x-ray/underground view |
| 15:36 |
paradust |
oops |
| 15:37 |
paradust |
Wikipedia has a chart here: https://en.wikipedia.org/wiki/OpenGL_Shading_Language#Versions |
| 15:37 |
paradust |
second table |
| 15:40 |
paradust |
I'm using the WebGL1 irrlicht backend which extends the GLES2 driver |
| 16:46 |
erle |
paradust it might not work anyway with some shaders because the number of instructions exceed the limit set by OGLES2. so if that could be fixed, it would be nice too. |
| 16:51 |
erle |
in fact, i do have hardware which supports OGLES2 but the rendering looks absolutly crap in minetest. someon told me it is the same issue with the mali 400 GPU. |
| 16:51 |
erle |
so if i want to optimize shaders so they fit, where would i start to learn about it? |
| 16:52 |
erle |
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.3.5 |
| 16:52 |
erle |
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16 |
| 17:32 |
paradust |
hm, I haven't encountered an instruction limit yet. But I'm stealing dealing with basic compile errors |
| 17:33 |
paradust |
Where to learn shader programming? I'm not the expert, for sure |
| 17:33 |
paradust |
I'm piecing it together from what I learned messing around with Unity, and skimming the OpenGL/GLES docs |
| 17:34 |
erle |
paradust basically, the question of conformance to the OGLES2 specification is defined by *passing the tests*. which means that you are only guaranteed to run on all GOLES2-capable hardware if you adhere to the *minimum* supported shader size. |
| 17:35 |
erle |
i guess the mali 400 GPU is probably an uncommon case, but AFAIK older intel hardware just matches those limits exactly. |
| 17:35 |
erle |
or rather, i am under the impression that minetest shaders exceed the size guaranteed by the spec |
| 17:35 |
erle |
to work |
| 17:36 |
erle |
paradust, basically, if you make shaders work with #version 100 this might solve my problems too, so if i can help, tell me how. |
| 17:36 |
paradust |
I'm having trouble getting them to even compiler, because they use syntax that's not supported in OGLESv2. So I can believe there must be more issues. It seems untested |
| 17:36 |
paradust |
*to even compile |
| 17:36 |
erle |
oh well, that explains a lot |
| 17:38 |
erle |
paradust, this is what minetest with OGLES2 looks like on my hardware https://mister-muffin.de/p/7RdQ.png |
| 17:38 |
erle |
paradust, inventory looks like this sometimes lol https://mister-muffin.de/p/2OBT.png |
| 17:39 |
sfan5 |
it definitely works on OpenGL ES 2.0 supporting hardware/drivers, if anything that'll be yet another webgl specific thing |
| 17:39 |
sfan5 |
and no, downgrading the version won't fix your broken drivers |
| 17:47 |
erle |
well, do you have any idea what exactly would be broken to make distant stuff black? |
| 17:51 |
sfan5 |
the shaders, probably |
| 18:02 |
erle |
sfan5 i am trying glslangValidator to figure out the features that might exceed specifications. have you experience with that? |
| 18:02 |
erle |
it claims that if it accepts a shader, than all conformant implementations accept it |
| 18:02 |
sfan5 |
no |
| 18:04 |
erle |
so here is one error message it spits out: 'scalar swizzle' : not supported with this profile: es |
| 18:04 |
erle |
(from minetest 5.4.1 shaders) |
| 18:05 |
erle |
i bet this is a case where most desktop GL things support this though |
| 18:16 |
erle |
sfan5, if you have debian, you can install the package glslang-tools. the validator defaults to ES version 100, but can also do desktop version 110 |
| 18:27 |
paradust |
I realized the shaders actually compile fine for me without shadows enabled |
| 18:27 |
paradust |
The problem sections seem to be protected by ifdef's for shadows |
| 18:28 |
paradust |
dynamic shadows |
| 18:30 |
erle |
i believe the shaders are actually not correct even without shadows |
| 18:30 |
erle |
take this one: https://github.com/minetest/minetest/blob/master/client/shaders/stars_shader/opengl_fragment.glsl |
| 18:30 |
erle |
it's super simple |
| 18:31 |
erle |
but thefloat type requires a default precision |
| 18:31 |
erle |
if i add the line “precision mediump float;” it passes strict validation. without, it does not. |
| 18:32 |
erle |
i believe that these shaders were written by people who know *desktop* GLSL |
| 18:32 |
erle |
and then thought that would neatly map to ES, but it does not |
| 18:32 |
erle |
https://stackoverflow.com/questions/28540290/why-it-is-necessary-to-set-precision-for-the-fragment-shader |
| 18:32 |
paradust |
erle: https://github.com/minetest/minetest/blob/master/src/client/shader.cpp#L646 |
| 18:33 |
erle |
oh i see! |
| 18:33 |
erle |
i eat my words |
| 18:33 |
erle |
oh lol |
| 18:33 |
erle |
so it is using the same code and then adding different prefixes |
| 18:33 |
paradust |
yup |
| 18:33 |
erle |
let's see what happens if i add the prefixes |
| 18:51 |
erle |
paradust, this is my shader validation shell script: am i missing anything? if so, what? https://mister-muffin.de/p/PsXP.txt |
| 18:52 |
erle |
oh, i can make it do both desktop and ES |
| 18:53 |
paradust |
that code adds much more to the prefix |
| 18:53 |
paradust |
https://github.com/minetest/minetest/blob/master/src/client/shader.cpp#L707 |
| 18:54 |
erle |
this sucks |
| 18:54 |
erle |
this is the job of a build system |
| 18:54 |
paradust |
can't, it's very dynamic. if you adjust graphics settings, it recompiles the shaders with new defines |
| 18:55 |
paradust |
I guess you could try to cover every possible combination |
| 18:55 |
paradust |
that'd be better for testing |
| 18:56 |
erle |
given the combinatorial explosion you claim i am VERY sceptical that this is valid in all cases |
| 19:02 |
erle |
sfan5, any idea how to dump the compiled shaders? |
| 19:03 |
erle |
sfan5, sorry, i mean the generated source code. not the compilate |
| 19:03 |
Krock |
hijack where the shaders are loaded, after the header #definitions |
| 19:03 |
paradust |
if you build your own minetest, you can dump it here: https://github.com/minetest/minetest/blob/master/src/client/shader.cpp#L790 |
| 19:03 |
paradust |
add a few lines above it to store the strings to files |
| 19:04 |
erle |
seems that dumpShaderProgram() is only called if generation fails |
| 19:04 |
paradust |
dumpShaderProgram prints it to the screen with line numbers |
| 19:05 |
erle |
oof |
| 19:05 |
paradust |
you need to modify the code to pull it out, there's no way to force it out with the existing code |
| 19:05 |
paradust |
well, I guess you could add some junk to force it to fail to compile, and then extract it from the dump |
| 19:05 |
erle |
well that sucks |
| 19:05 |
paradust |
but the dump is a mess |
| 19:06 |
paradust |
you can clean it up of course |
| 19:06 |
erle |
i think the easiest way to assist to your goal of #version 100 compat is to a) dump shaders b) feed them to the validator |
| 19:07 |
paradust |
Actually, since I know the issue is just dynamic shadows, I'll probably put it aside for now. |
| 19:07 |
erle |
damn |
| 19:07 |
paradust |
I have a full dump of the compile errors |
| 19:07 |
erle |
i thought you'd be provoked into action by my remark |
| 19:08 |
erle |
and make a dump functionality ;> |
| 19:08 |
erle |
silly hope i know |
| 19:10 |
paradust |
I have 100 other things to fix. Have to pick my battles |
| 19:19 |
paradust |
does your exotic hardware run chrome/chromium/firefox/or safari? |
| 19:21 |
sfan5 |
paradust: dynamic shadows not working on gles is a known limitation |
| 19:34 |
paradust |
i see |
| 19:34 |
paradust |
erle: if your gles2 hardware can surf, I'd be curious if it works with: https://minetest.dustlabs.io/beta/ |
| 19:38 |
sfan5 |
I'm surprised how good the performance is, is it wasm? |
| 19:39 |
paradust |
yea |
| 19:39 |
MTDiscord |
<x2048> heh, dynamic shadows are not even finished yet :) |
| 19:41 |
paradust |
Shaders just improved performance by 50% or so |
| 19:41 |
paradust |
But it's now crashing with glBufferSubData overflow pretty frequently. Still needs debugging |
| 19:42 |
paradust |
x2048: ah |
| 19:49 |
MTDiscord |
<x2048> erle: let me finish #12195, and I'll give you a dump of the shaders |
| 19:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/12195 -- Improve shadow filters by x2048 |
| 20:02 |
erle |
x2048 in case you yearn for additional work, make it a command line flag? ;) |
| 20:03 |
erle |
i.e. start minetest, dump shaders |
| 21:02 |
MisterE[m] |
sfan5, please check out: https://github.com/minetest/minetest/issues/12092#issuecomment-1107643967 |
| 21:04 |
MisterE[m] |
please examine the bug test mod, log in to the server, and follow the instructions to test the bug. Also install the mod in singleplayer to see that the bug only occurs in multiplayer |
| 21:04 |
sfan5 |
you guys dont need to keep a server running for reproduction you know |
| 21:05 |
sfan5 |
latency induced bugs are easy to test locally on linux |
| 21:06 |
MisterE[m] |
hmmm... well, its on a server I run anyways, and it doesnt break gameplay |
| 21:07 |
MisterE[m] |
so I dont mind running it. This bug is breaking mine and Zughy's minigames servers, and the workaround is not a 100% solution. I would really like this fixed in 5.6 |
| 21:07 |
sfan5 |
(https://daniel.haxx.se/blog/2010/12/14/add-latency-to-localhost/ for anyone wondering) |
| 21:07 |
sfan5 |
sure, was just saying |
| 22:07 |
erle |
MisterE[m] so the workaround is to use minetest.after(0, ...) or so? |
| 22:32 |
|
panwolfram joined #minetest-dev |
