Time Nick Message 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 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 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?