00:11karolherbst[d]: gfxstrand[d]: the descriptor set is available in the command buffer, right? Maybe you could just bind them via a macro...
00:22gfxstrand[d]: That's what I do on Turing. It reads the descriptor set and emits a cbuf command. On Maxwell, though, that requires splitting the batch, making it potentially several pushbufs per draw
00:23karolherbst[d]: why does it require splitting the batch?
00:36gfxstrand[d]: The current approach reads the descriptor from VRAM on the GPU. We can read from the MME on Turing.
00:37gfxstrand[d]: On Maxwell, I either need a CPU shadow copy of the descriptor set or I need to split the batch because that's how you do indirects pre-turing
00:37gfxstrand[d]: `Pass: 113423, Fail: 13, Crash: 13, Skip: 160742, Timeout: 2, Duration: 14:03, Remaining: 0`
00:37gfxstrand[d]: Clean dmesg
00:37karolherbst[d]: ohh, right...
03:49gfxstrand[d]: Down to 2 bugs vs. maxwell (and indirect compute dispatch). Some weird GS thing and some ALU bug that only shows up in NIR's lowered 64-bit divide.
05:18gfxstrand[d]: It's a bug with iadd64. 😭
05:18gfxstrand[d]: Which I thought I tested the shit out of
05:41gfxstrand[d]: Well, lowering iadd64 fixes it. It could be a bug in RA for all I know. 🤷🏻♀️
06:51AFilius: Hello Goof Morning.
06:53AFilius: anyone can help we with reported issue, and the merge request i made? (v6.9.9), just like to know if i need to do something to push it forward
06:56AFilius: It's about issue: https://gitlab.freedesktop.org/drm/nouveau/-/issues/377
06:56AFilius: and MR: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/25
06:58DodoGTA: AFillus: Your merge request was mentioned once in this channel (but no one responded to it)
07:01AFilius: DodoGTA: As it seems the pipeline doesn't get triggered as it seems in my MR, so it will never get green, idead how that works?
07:02AFilius: All branches are locked, i guess that has all to do with it
07:18AFilius: While having fixed my crash on my Lenovo T430+GPU, i tried to undock it, while having 2 external screens. while docking back, the nouveau driver doesn't seem to take the efford to rescan the displays. andy hint perhaps where i can start looking? if i perform a: # /sys/kernel/debug/dri/0000:01:00.0/DP-2# cat output_bpc cat: output_bpc: No such device
07:19AFilius: where DP-2 (and DP-3)was just available before the undock/dock test
07:24AFilius: if i look into root@arjan-ThinkPad-T430:/sys/kernel/debug/dri/0000:01:00.0/state i see plane[54] and plane[64] crt-ps has values related to my monitors, but connector[48] and connector[51] (DP-2 and DP-3) says crtc=(null) assuming state no monitor attached
07:31redsheep[d]: AFilius: I don't follow the kernel work too closely, but so far I have only seen things get merged by working through the nouveau mailing list https://lists.freedesktop.org/mailman/listinfo/nouveau
07:32AFilius: redsheep[d]: thanks for the hint
08:35karolherbst: AFilius: well.. it needs somebody with knowledge about the code to take a look and it's also the weekend
08:36karolherbst: your patch might be fine, but it might also just papering over the issue and not actually fixing it
08:37karolherbst: AFilius: also.. it seems like you have the iommu enabled?
08:37karolherbst: I see some iommu related errors in your log, and maybe it's something nouveau doesn't set up correctly
12:05AFilius: KarolHerbst: i might have iommu enabled, not intentionally, just performed a fersh ubuntu 24.04 install, and recompiled a virgin v6.9.9 kernel.
12:07AFilius: karolherbst: i'm pretty sure the actual root cause might be from somwhere else, and it might be even better fixed in another place, i'm happy to look at it again , but on the other hand i just touched the nouveau code for first time
12:10AFilius: Karolherst: regarding iommu, i don't use virtualisation, nor GPU passthrough on this system