09:28 <lynxeye> mntmn: Do you remember what happened if you didn't set that second 1 bit in the 0x11000031 RA_EARLY_DEPTH config?

09:48 <mntmn> lynxeye: i think it looked like depth writes or tests not happening

09:49 <mntmn> lynxeye: i can check again real quick, but it might hang without toggling the ra-write-depth related bit

10:15 <mntmn> lynxeye: http://dump.mntmn.com/screenshot-2020-07-03-12-13-48.png

10:15 <mntmn> lynxeye: http://dump.mntmn.com/screenshot-2020-07-03-12-13-52.png

10:15 <mntmn> lynxeye: http://dump.mntmn.com/screenshot-2020-07-03-12-13-48.png

10:16 <lynxeye> mntmn: cool, thanks! That's with RA_EARLY_DEPTH 0x10000031?

10:16 <mntmn> lynxeye: this is what happens with cs->RA_DEPTH_CONFIG = 0x10000031

10:16 <mntmn> yes

10:16 <mntmn> i'm not 100% sure how to interpret this though

10:17 <mntmn> ah i sent one link twice

10:18 <mntmn> lynxeye: for completeness http://dump.mntmn.com/screenshot-2020-07-03-12-14-13.png

10:18 <mntmn> lynxeye: any theories? it looks like depth testing goes wrong to me

10:19 <lynxeye> mntmn: I've had some time to think about this and I think my mental model of how those things work together in HW is finally getting somewhere. I may have a patch series for properly deriving the early Z states for you to test later.

10:19 <mntmn> lynxeye: oh cool, looking forward!

10:21 <mntmn> lynxeye: you're aware that GL_ALPHA_TEST also changed somehow with halti5 (?), right?

10:21 <lynxeye> mntmn: It looks like this bit controls some depth testing on a vertex basis instead of doing it on fragments.

10:21 <mntmn> interesting

10:21 <lynxeye> mntmn: Yep, alpha test is probably a related issue, as it won't work with early depth writes

10:22 <mntmn> yeah

10:30 <mntmn> i have another topic where i'm not sure with what tools to investigate. when i play minetest for a bit longer (several minutes up to half an hour) with NIR, i'll get a gpu hang/crash reliably, but not with TGSI.

10:33 <lynxeye> mntmn: for sporadic hangs it's very useful to look at the GPU state at the time of the hang. Etnaviv allows you to collect a devcoredump on a hang.

10:34 <mntmn> lynxeye: is that an option in the kernel module?

10:36 <lynxeye> mntmn: The kernel driver always includes the coredump functionality, you just need a bit of userspace helpers to collect the dump. Give me a minute to dig it up

10:36 <mntmn> ok, thanks!

10:38 <lynxeye> mntmn: https://pastebin.com/wFLCJzU9

10:39 <lynxeye> udev rule to trigger script when a coredump pops up and then just collect it and write it out compressed

10:40 <lynxeye> you can then use the etna-gpu-tools to dissect the dump and work backwards through the GPU states from the hang

10:40 <austriancoder> mntmn: you used this mechanism already :)

10:41 <mntmn> austriancoder: i have? :3

10:41 <mntmn> ah maybe a longer time ago!

10:53 <mntmn> ok devcoredump happened

10:54 <mntmn> here's my minetest crash. the application doesn't recover from it, it stays frozen with a corrupted screen. http://dump.mntmn.com/devcoredump-20200703125251.bin.gz

10:56 <mntmn> looks like this in crashed state: http://dump.mntmn.com/screenshot-2020-07-03-12-54-53.png

16:21 <dos1> mntmn: FWIW I see something similar with mesa 20.1 and neverball. didn't happen on 20.0.x

16:21 <mntmn> dos1: hmm!

16:22 <mntmn> ah, neverball doesn't start for me now because of "Semantic value not found in vertex shader outputs"

16:22 <mntmn> how did i fix that last time...

16:29 <senquack> this is probably not your issue, but on an old port of Neverball I did for GC860 w/ much older Etnaviv+MESA, I had to disable its use of GL 'billboards'

16:29 <senquack> IIRC it uses those for the star effects at level completion

16:30 <mntmn> hmmm. i should have written that down, i'm pretty sure i'd fixed this problem before somehow

18:05 <flto> mntmn: probably using NIR backend

19:31 <mntmn> flto: no, with TGSI it's "Semantic 19 value 2 not found in vertex shader outputs"