00:08Akari: wiped the cache and now seemingly every shader in my game is causing the crash
00:11Akari: worth noting that it only happens with ASan. But my test program segfaults inside Mesa even without ASan, and has a different stack trace
00:11Akari: so it might be a different but related issue
00:23Akari: ok the difference in my test program is that I accidentally tried to compile a fragment shader as a vertex shader. Once I fixed that, the crash vanished completely. Even with ASan and empty cache. I don't know what the hell.
01:01Akari: well i reported it https://gitlab.freedesktop.org/mesa/mesa/-/issues/3131
01:02Akari: hope that's good enough
13:24bernie_: emersion: ptal https://github.com/ascent12/drm_info/pull/53
19:33DrNick: anyone looked at why Minecraft 1.16 misrenders on Mesa?
19:33DrNick: my inexpert apitrace examinations suggests they sample from a bunch of depth textures that they never once render to, which can't be right
19:34imirkin: DrNick: does it happen across drivers?
19:35DrNick: I don't have any other drivers to test
19:35DrNick: they specifically warn about Mesa being unsupported so presumably it works on nvidia
19:36DrNick: or maybe it only works on Windows/Mac OpenGL
19:39imirkin: DrNick: across different mesa drivers?
19:40DrNick: I guess I could try software rendering
19:42DrNick: yeah, also happens with LIBGL_ALWAYS_SOFTWARE=1
19:51imirkin: ok, probably they're doing something dodgy then
21:02karolherbst: heh.. how can I disable the lowering of indirect tess_eval inputs?
21:04imirkin: you probably know this, but there are PIPE_SHADER_CAP's which indicate what's supported. the nir thing probably just doesn't respect them
21:06karolherbst: yeah.. I scanned thorugh that but no name indicated what I search for...
21:06karolherbst: maybe I should scan through the docs actually
21:06imirkin: right, dunno about the nir end
21:06imirkin: just saying that the driver is able to advertise support for the various things through PIPE_SHADER_CAP's currently
21:07karolherbst: and those bits look fine
21:07karolherbst: like PIPE_SHADER_CAP_INDIRECT_INPUT_ADDR
21:07imirkin: and st_glsl_to_tgsi respects these
21:08karolherbst: yeah.. maybe I check there.. could be that for nir it's always turned on or so
21:08imirkin: not 100% sure, but i think nvidia is unusual in its ability to support indirect indexing for inputs/outputs
21:09karolherbst: with volta they don't support it in fragment shaders anymore though
21:09imirkin: so it could be that no one's looked at it
21:09imirkin: for inputs, or outputs? frag output indirect indexing was never supported anywhere
21:09karolherbst: both :p
21:09imirkin: ah ok
21:09karolherbst: a bit surprising but yeah
21:09karolherbst: I bet they have a good reason for it though
21:10karolherbst: maybe the hardware support is too complex and not worth it
21:10imirkin: well, it's a lot of things to have to change depending on how the varying is set up
21:42karolherbst: ohh uhm... loop unrolling this this here actually...
21:47karolherbst: this huge if ladder got me.. but that is actually part of the loop body
22:01karolherbst: can we disable the nir loop unrolling when there are structures inside the loop? like ifs?
22:01karolherbst: this is really harmful for us
22:04imirkin: unrolling should probably be based on the "amount" of code inside the loop
22:04imirkin: the glsl unrolling has a limit iirc
22:05karolherbst: yeah.. but I think we limit it based on the iterations... and unrolling bigger loops is not a problem
22:05karolherbst: just.. if there are structures then it hurts
22:05imirkin: you might be right.
22:06karolherbst: like I have a shader here were I need to enable the off chip call return stack
22:06karolherbst: after unrolling
22:06karolherbst: those are the nir shaders: https://gist.github.com/karolherbst/7e749aa6cb56e8de9245b11e89c9d621
22:06karolherbst: you'll see the issue :)
22:06imirkin: i trust you
22:06imirkin: doing some other stuff, can't look in detail
22:06karolherbst: ahh, okay