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