02:26fdobridge: <airlied> @georgeouzou transform feedback tests are regressing now, need to whack more moles
02:49fdobridge: <airlied> okay pushed the branch, the opt loop doesn't crash xfb now
03:37fdobridge: <esdrastarsis> @ttabi I think GSP is broken on tu117 (gtx 1650) in the last update from Ben's kernel tree (00.02-gsp-rm), the display freezes on boot.
03:37fdobridge: <esdrastarsis> I'm using HDMI so it's TMDS I think
04:26fdobridge: <airlied> @gfxstrand @georgeouzou okay with the current tess branch I'm not seeing any regressions or broken tests (beyond the usual noise)
04:26fdobridge: <airlied> @gfxstrand maybe you can run it on one of your test runs
04:30fdobridge: <gfxstrand> Sure. I'll run it tomorrow
05:16fdobridge: <georgeouzou> Nice! I will test also in the afternoon
16:31fdobridge: <ttabi1> @esdrastarsis It crashes on load on my TU104. I did some debugging and sent Ben my findings yesterday, but no response.
16:39fdobridge: <gfxstrand> Doing a full CTS run of Tess on my RTX 2060 now.
17:58fdobridge: <gfxstrand> Why is the Tessellation MR breaking SSBO tests?!?
17:59fdobridge: <gfxstrand> Oh, right, because @airlied added an optimization loop....
17:59fdobridge: <airlied> I wonder if I should pull the opt loop into a separate MR
18:00fdobridge: <airlied> and deal with the fallout from it first, what ssbo pattern is failing?
18:01fdobridge: <gfxstrand> A bunch of robustness2 tests are failing and also a bunch of `dEQP-VK.ssbo.*row_major*`
18:02fdobridge: <gfxstrand> It's almost certainly the nouveau load/store combining pass going awry
18:03fdobridge: <karolherbst🐧🦀> ahh yes...
18:03fdobridge: <karolherbst🐧🦀> please don't use memoryopts
18:03fdobridge: <gfxstrand> Is there a way to just disable that pass?
18:03fdobridge: <karolherbst🐧🦀> yeah, just disable it 😄
18:03fdobridge: <karolherbst🐧🦀> remove the code calling into it
18:03fdobridge: <gfxstrand> I'm already running with NV50_PROG_OPTIMIZE=1
18:03fdobridge: <gfxstrand> lol
18:03fdobridge: <karolherbst🐧🦀> I've had it disabled for CL work all the time
18:04fdobridge: <karolherbst🐧🦀> `MemoryOpt` even has compute checks for indirects "because alignment issues"
18:04fdobridge: <karolherbst🐧🦀> it's very conservative for compute shaders
18:05fdobridge: <karolherbst🐧🦀> a lot of codegen assumes `vec4` alignment for input/output
18:05fdobridge: <karolherbst🐧🦀> well.. not a lot, but `MemoryOpt` is one of those places
18:05fdobridge: <gfxstrand> Oh, no, it looks like codegen is failing to spill for those shaders
18:06fdobridge: <gfxstrand> Maybe we should just switch to NAK, spilling or no. 😂
18:06fdobridge: <gfxstrand> Sometimes I forget just how low the bar is...
18:08fdobridge: <karolherbst🐧🦀> yeah.....
18:08fdobridge: <karolherbst🐧🦀> RA in codegen is.... uhm...
18:08fdobridge: <karolherbst🐧🦀> "weird"
18:08fdobridge: <karolherbst🐧🦀> I'm convinced it's broken beyond repair
18:08fdobridge: <karolherbst🐧🦀> I actually know what the problem is
18:08fdobridge: <karolherbst🐧🦀> I just concluded that the algorithm is broken
18:08fdobridge: <karolherbst🐧🦀> the code is fine, but the way it interprets the underlying algorithm is just not panning out
19:49fdobridge: <dadschoorse> I think aco was merged without spilling
19:49fdobridge: <dadschoorse> but back then it wasn't the default 🐸
20:05cwabbott: karolherbst: I figured it out at some point, the problem was the way it was trying to be clever about spilling
20:06cwabbott: like, usually you have to keep repeatedly spilling and re-calculating the interference graph until it can finally allocate
20:06cwabbott: and nv50 was trying to spill everything in one go and re-allocate once, but it doesn't actually work
20:10karolherbst: yeah.. something like that
20:10karolherbst: but the calculation of the weights is also broken
20:11karolherbst: like I can make it fail trying to do RA with 19? live values, because the way it tries to find stuff to spill is a bit bonkers
20:12karolherbst: it's a bit of a mess, but my conclusion was to torch the way codegen was doing RA
20:22fdobridge: <gfxstrand> Alright. Let's merge this. I think we can handle the minor fallout.
21:37fdobridge: <gfxstrand> After substantial refactoring and re-base headaches to deal with multi-plane, I think I'm reasonably happy with the d32s8 patch now.
21:37fdobridge: <gfxstrand> CI is running. We'll see if I broke it. 😅
21:41fdobridge: <gfxstrand> CTS/ is running. We'll see if I broke it. 😅 (edited)
21:41fdobridge: <gfxstrand> CTS is running. We'll see if I broke it. 😅 (edited)
21:41fdobridge: <gfxstrand> TIL: You can type `s/foo/bar` into discord and it will edit your last message...
21:46fdobridge: <esdrastarsis> Here the dmesg says there was a General Protection Fault, do you have the same problem?
21:47fdobridge: <ttabi1> [ 62.584159] general protection fault, probably for non-canonical address 0xaa11038ba54e5171: 0000 [#1] PREEMPT SMP PTI
21:47fdobridge: <ttabi1> Like this?
21:48fdobridge: <esdrastarsis> Yes
21:48fdobridge: <ttabi1> I believe the problem is that Nouveau is double-freeing (or something like that) firmware image
21:49fdobridge: <ttabi1> https://www.irccloud.com/pastebin/VMuLWlhO/
21:50fdobridge: <ttabi1> tu102_gsp_booter_ctor is trashing fw->priv, I think
21:52fdobridge: <ttabi1> I'll try an Ampere
21:58fdobridge: <gfxstrand> The good news is that multi-plane actually made it easier. The scratch area is now just a plane.
22:03fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> So will that get merged?
22:07fdobridge: <airlied> have to help @phomes figure out cond render next to get the zink dream 🙂
22:12fdobridge: <airlied> I should update my turing to latest gsp code and see how it goes, but probably next week
22:19fdobridge: <esdrastarsis> let me know if it works
22:20fdobridge: <esdrastarsis> There is a possibility that the reason for the problem is `nvkm_firmware_put(blob);` on `goto done`?
22:36fdobridge: <ttabi1> Yeah, something like that. I didn't dig any deeper into the code.
22:42fdobridge: <gfxstrand> Already done. 😁
22:42fdobridge: <gfxstrand> @airlied How are we doing on uAPI stuff? I've not been paying that much attention.
22:49fdobridge: <ttabi1> @esdrastarsis I get further along on an Ampere, but I hit a WARN_ON in r535_gsp_init
22:50fdobridge: <ttabi1> actually, except for the WARN_ON, it seems to load
22:53fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Updated my issues accordingly
22:54fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Make sure to update yours too: https://gitlab.freedesktop.org/nouveau/mesa/-/issues/24