13:05pac85: Is there a way of generating a caselist from the Fails in a TestResult.qpa?
13:11daniels: cut -f1 -d, < failures.csv > caselist.txt
13:22pac85: daniels: thx though how do I get the failures.csv? I only get a .qpa file after running deqp
13:22zmike: failures.csv is produced by deqp-runner
13:22daniels: pac85: https://gitlab.freedesktop.org/mesa/deqp-runner is the tool you want
13:23pac85: Ah thx
16:55glehmann: jenatali: looks like your compiler incorrectly assumes phis sources have a specific order https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42321
17:12jenatali: glehmann: Sigh, of course it does
17:15jenatali: I'm just getting back from vacation, lemme see if I can take a look today but it might need to wait if there's other urgent things
17:17glehmann: it's not super important, so take your time
17:45mareko: vc4 and vmware jobs always time out when executed manually, is that expected?
17:55karolherbst: I'm sure here are people knowing how to optimize logic op LUT ops and in NAK we are seeing this pattern emerge in bitfield_insert lowering: (lop3[LUT_A], a, #b, (lop3[LUT_B], c, ~#b, 0)) and I was wondering if there is a good read up or anything on how to merge such logic op LUT ops
17:56karolherbst: was considering implementing bitfield_select, which we can do in one lop3 op, but that really hits some constant folding cases and gives me worse shaders in a couple of cases and I'd rather not mess with the lowering there to make that more optimal.. dunno
18:02gfxstrand: optimally folding lop3 is hard
18:13karolherbst: gfxstrand: don't worry, mel and I came up with a plan: we normalize all constant lop sources with the high bit to be 0, then NAK folds them, because the sources are now equal :)
18:21karolherbst: but I've also noticed other interesting patterns: LUT_A a, b, c == LUT_A, c, ~b, a, not sure if that's a general thing though
18:21karolherbst: or LUT_A a, b, c == ~LUT_A, c, b, a
18:22karolherbst: ehh not sure if that's one actually true