00:11fdobridge: <gfxstrand> I think I need re-convergence...
00:21fdobridge: <gfxstrand> I think that's tomorrow's problem
09:34Mary: anholt: karol told me that you had a similar issue on Tegra boards with nouveau, any ideas? https://gist.github.com/marysaka/ba1f887a7460a45aa54a706fd6f95875
09:38Mary: (I can only reproduce that on 6.6-next, on 6.5.6 it works fine)
10:23fdobridge: <karolherbst🐧🦀> to clarify: the issue was something iommu related, maybe there was always some weird memory corruption going on?
13:29kwizart: Mary: can you reproduce with nouveau loading been delayed ? (using rd.driver.blacklist=nouveau ) ?
15:13anholt: Mary: not quite, that looks like new failure.
15:13Mary: kwizart: same thing, also tried with modprobe.blacklist and loading it manually and it resulted to the same thing
15:14Mary: I guess I'm off building a 6.5 kernel with the userland patches that NVK needs for now ^^'
16:16fdobridge: <gfxstrand> @karolherbst What's the opcode for BREAK? on Turing+?
16:16fdobridge: <gfxstrand> If you want to throw me the other bits too, that'd be great, but the opcode is the thing that's hard to RE
16:17fdobridge: <karolherbst🐧🦀> I don't have the encodings
16:17fdobridge: <gfxstrand> I thought you did
16:17fdobridge: <gfxstrand> 😭
16:17fdobridge: <karolherbst🐧🦀> sadly I don't 😦
16:17fdobridge: <gfxstrand> So I have to con the blob into generating it?
16:17fdobridge: <gfxstrand> Okay...
16:18HdkR: The secret sauce of NVIDIA, the ISA encoding
16:18fdobridge: <karolherbst🐧🦀> yeah...
16:18fdobridge: <karolherbst🐧🦀> for whatever reason 😄
16:18fdobridge: <gfxstrand> I think I have a NIR pass which inserts them and most of the NAK code to generate them.
16:18fdobridge: <karolherbst🐧🦀> @gfxstrand just write a script to dump all instructions... I mean there are like 11/12? bits for the op encoding?
16:19fdobridge: <gfxstrand> Yeah, but I need lots of valid bits or a bunch of them don't disasem
16:19fdobridge: <gfxstrand> But I can try
16:19fdobridge: <karolherbst🐧🦀> right...
16:19fdobridge: <karolherbst🐧🦀> but break shouldn't have that
16:19fdobridge: <karolherbst🐧🦀> it takes one barrier register...
16:20fdobridge: <mhenning> I have that 0x028 is `break_inst_` from some RE stuff
16:20fdobridge: <mhenning> on sm75
16:22fdobridge: <gfxstrand> ```
16:22fdobridge: <gfxstrand> Test case 'dEQP-VK.subgroups.ballot.compute.compute'..
16:22fdobridge: <gfxstrand> Pass (OK)
16:22fdobridge: <gfxstrand> ```
16:22fdobridge: <gfxstrand> Here we go!!!!
16:22fdobridge: <gfxstrand> Nice! I'll try that
16:24fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> NVK election (real) 🗳️
16:29fdobridge: <mhenning> I just uploaded the list of opcodes I found and the script to generate them here, in case it's useful for other stuff: https://gitlab.freedesktop.org/mhenning/re/-/tree/main/opclass?ref_type=heads
16:30fdobridge: <gfxstrand> I just need I'm confused... You have 0x027 as bsync but I'm using 0x941
16:31fdobridge: <mhenning> Sometimes an opcode shows up multiple times as different forms
16:31fdobridge: <karolherbst🐧🦀> bsync only has one form tho
16:32fdobridge: <gfxstrand> Or not? 🤷🏻♀️
16:32fdobridge: <gfxstrand> I'll play around
16:52benjaminl: look at the script, I think all of the recorded opcodes are `+ 0x791a`
16:52benjaminl: since it has `vals += i`, and `vals & 0xffff == 0x791a`
16:53benjaminl: yeah, that's it: `0x027 + 0x791a == 0x7941`
16:54karolherbst: some of the opcodes are also hidden if you don't set the "uniform reg" bit
16:55karolherbst: and I think there are two of them, for the second and third source
16:55benjaminl: so this would put break at 0x942
16:56benjaminl: ah yeah, I got it: `000ff600 00000000 00000000 0000094` => `@P0 BREAK P0, B0`
16:57benjaminl: or, missing the final `2` there, but yeah
18:00fdobridge: <mhenning> oh, hah I forgot to zero that out
18:02fdobridge: <mhenning> I suppose you can tell it isn't a very carefully tested script
18:07fdobridge: <mhenning> The uniform reg thing is good to know - I realized the script was missing stuff because you need to set additional bits for some ops to show up, but I wasn't sure which bits they were.
19:31benjaminl: thoughts on having a separate legalize_sm50 pass in nak versus just adding a bunch of branches for sm50 in the existing legalize pass?
20:49fdobridge: <gfxstrand> Probably a good idea
21:17fdobridge: <gfxstrand> Time to see how much of a disaster I made by adding re-convergence. 😰
21:18fdobridge: <gfxstrand> Time to see how much of a disaster I made by adding re-convergence. 😅 (edited)
21:19fdobridge: <gfxstrand> I'm getting lots of these so that's a good sign:
21:19fdobridge: <gfxstrand> ```
21:20fdobridge: <gfxstrand> [ 383.182311] nouveau 0000:17:00.0: deqp-vk: channel 20 killed!
21:20fdobridge: <gfxstrand> [ 387.656001] nouveau 0000:17:00.0: fifo:000000:000e:[deqp-vk] rc scheduled
21:20fdobridge: <gfxstrand> [ 387.656010] nouveau 0000:17:00.0: fifo:000000: rc scheduled
21:20fdobridge: <gfxstrand> [ 387.656034] nouveau 0000:17:00.0: fifo:000000:000e:000e:[deqp-vk] errored - disabling channel
21:20fdobridge: <gfxstrand> ```
21:20fdobridge: <gfxstrand> And some bad instruction encodings, just for good measure.
21:20fdobridge: <gfxstrand> I suspect loops are busted