07:11marysaka[d]: airlied[d]: I have ~24 failures with NAK_DEBUG=serial but I think those are CTS bugs, without it I get some faults
07:12marysaka[d]: There is also still LDSM to wire
07:31marysaka[d]: but yeah apart from that it matches what NVIDIA blobs expose on Turing/Ampere/Ada
08:26gfxstrand[d]: snowycoder[d]: 80% fail is the first step
11:42snowycoder[d]: gfxstrand[d]: The issue is due to some kind of synchronization fail (it goes away if I push a `WAIT_FOR_IDLE`, but it forces a device sync).
11:42snowycoder[d]: I have 0 experience with MME assembly so I can't find nvidia sync solution (seems to be something with `SET_MME_SHADOW_RAM_CONTROL` or `SET_SCISSOR_*` but I can't even find when the macro is called)
11:50gfxstrand[d]: That's odd...
11:51gfxstrand[d]: Most state is properly pipelined. I don't know why window clip would be different.
11:51gfxstrand[d]: Can you push a draft MR? That's the easiest way for me to look at your code.
12:40gfxstrand[d]: Ugh... I kinda hate NAK's CFG data structure.
12:40gfxstrand[d]: Well, really, I dislike the way some of the Rust stuff maps WRT mutability.
12:50gfxstrand[d]: But it's correct so oh well
12:53gfxstrand[d]: I think I have the recursion out of repair_ssa()
12:53gfxstrand[d]: CTSing now
13:00gfxstrand[d]: Let's see if Veilguard starts without whacking the wine stack size now.
13:01gfxstrand[d]: We also have some NIR passes which might need the same treatment. 😕
13:16gfxstrand[d]: Yup! CTS is good and that fixes Veilguard.
13:22gfxstrand[d]: mhenning[d]: If you'd care to review: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33472
13:23gfxstrand[d]: mhenning[d]: Normally I just push my stuff but that one wouldn't mind a second set of eyes.
14:30snowycoder[d]: gfxstrand[d]: I'm waiting for account approval on freedesktop's gitlab (https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/2040)
14:30snowycoder[d]: In the meantime I uploaded my changes on a personal fork over gitlab.com https://gitlab.com/SnowyCoder/mesa/-/commit/3a5eb92d35a4ba70bdf53fd2480e5eb5ab02512d
14:57snowycoder[d]: gfxstrand[d]: Account was approved! here's the draft MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33476
15:58gfxstrand[d]: snowycoder[d]: Does everything pass with WAIT_FOR_IDLE? Or just more stuff?
15:59snowycoder[d]: Every test passes reliablt with `WAIT_FOR_IDLE`
15:59snowycoder[d]: Also, tests seem to always pass if I run them alone (with no other testcase)
16:01snowycoder[d]: Wait, maybe I just got lucky, let me redo the tests a bunch of times
16:06snowycoder[d]: Sorry, I got lucky and had a 100% pass run, sometimes though some cases fail
16:07snowycoder[d]: Do you have any pointers on what could the issue be?
16:12gfxstrand[d]: Yeah, I've got an idea or two. Commenting now.
16:17gfxstrand[d]: I suspect it has to do with defaults. See gitlab.
17:44mhenning[d]: gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32517 should be ready for a review when you get a chance
18:59mhenning[d]: Is there an existing way to run the MME sim on a macro I dumped from the prop driver? I'm having a bit of trouble following the control flow just reading the disasm
19:20phomes_[d]: The new additional metadata validation landed and `NIR_DEBUG=extended_validation` is finding something in at least Snipe elite 3. I tested on a few other games without problems. I will file an issue for sniper elite 3 and test some more
19:42gfxstrand[d]: mhenning[d]: Not at the moment
19:56marysaka[d]: I think I had some patches to run in the simulator some blob with arguments but can't remember where I did put that...
19:58mhenning[d]: gfxstrand[d]: So, there's a discrepancy in how mme branch instructions are evaluated where the simulator [does nothing in the else case](https://gitlab.freedesktop.org/mesa/mesa/-/blob/6b2b74a894d87c2208f24861e3d7c5ba5faba643/src/nouveau/mme/mme_tu104_sim.c#L313) while the printer [disassembles an offset for the else
19:58mhenning[d]: case](https://gitlab.freedesktop.org/mesa/mesa/-/blob/6b2b74a894d87c2208f24861e3d7c5ba5faba643/src/nouveau/mme/mme_tu104.c#L323). Do you know which interpretation matches hardware?
19:59gfxstrand[d]: Write more test cases?
20:04mhenning[d]: Fair enough. Just wanted to make sure you didn't have a mental TODO item
20:14gfxstrand[d]: Nope. No ToDo on that one
22:01magic_rb[d]: huh, so deep rock galactic wont open on nvk, unless i `PROTON_HIDE_NVIDIA_GPU=1`
22:03magic_rb[d]: https://paste.tomsmeding.com/t3yjMsQA are the relevant crash logs i could dig out
22:06karolherbst[d]: seems that it requires DLSS support
22:15mhenning[d]: magic_rb[d]: If you file a proton bug, they can probably add a workaround for that game
22:15magic_rb[d]: so i should file a proton bug then?
22:16mhenning[d]: Yes, please do
22:17magic_rb[d]: will do 🫡
22:17gfxstrand[d]: mhenning[d]: Looks good, I think. I'd like to have 64-bit support as well, though.
22:17magic_rb[d]: (im surprised that its detecting nvk as nvidia, did the "make the GPU name look like nvidia proprietary" patches already make it?)
22:18gfxstrand[d]: Yeah, we look a lot like proprietary from the strings.
22:19gfxstrand[d]: And D3D12 apps aren't driver-aware. They only know the driver from the vendor.
22:19magic_rb[d]: yeah this is d3d12
22:20magic_rb[d]: cool though, that nvk looks like proprietary already, i remember seeing the discussion, but then missed the conclusion
22:20magic_rb[d]: oh and aside from that little hiccup, game works great, thanks everyone :)
22:20gfxstrand[d]: Yeah, that happened a while ago. I don't remember when.
22:21gfxstrand[d]: But we print out both the marketing name and the chip number.
22:22magic_rb[d]: can we also get dlss? i remember that being a discussion too, about how every game ships its own dlss dll and that contains the whole proprietary blob of code which is directly shipped to the GPU
22:22magic_rb[d]: so it would just need wiring through dxvk/vkd3d
22:23gfxstrand[d]: Possibly? There's a lot of unknowns there because we have to be able to dispatch kernels compiled by the NVIDIA compiler.
22:23gfxstrand[d]: And that means figuring out their binary format at least enough to make compute work.
22:51magic_rb[d]: the game runs really well, some minor hiccups but those appear to be "the first time i do a thing it lags, then not a gain" so something something shaders? i did skip the precompile in steam because it was taking ages
23:41redsheep[d]: magic_rb[d]: Yeah that was me running into similar issues. There were a few moving parts last time but the proton people did get it working without environment variables. If that's not working again something regressed
23:43redsheep[d]: I was seeing quite a lot of stutter as well, and I had to turn on fsr2 upscaling to get reasonable framerates
23:48redsheep[d]: Oh that reminds me, I never did get around to testing that one perf branch on nvk.
23:48redsheep[d]: gfxstrand[d] Is that request to check for perf differences still relevant? I know you've been looking at a few different avenues there