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
14:22AFilius: in investigating on Lenovo T430+GPU+dock+2Screens using display port a 2nd issue: when pulled out of the dock, and back, the displayport screens on Dock "never" get to be used again. never? no! just found out that a simple "sudo lshw -C video" triggers something to maek the screens visable/usable again after undock/dock. anyone an idea perhaps where/which direction to look for more permanent out of the box soluti
14:48karolherbst: AFilius: I'd try disabling iommu and see if that changes anything first, because the IOMMU related errors might cause issues like that
15:05AFilius: karolherbst: thanks, never bothered iommu, as just handy option when using virtualisation. Just tested the T430. The undock/dock (using 2 DisplayPort screens) doesn't return (both stock ubuntu 24.04 kernel, and from git v6.9.9 compiled kernel. thanks! (the issue with device by 0 stays however)
15:06AFilius: So undock/dock issue is solved/masked by not using iommu (intel_iommu=off as kernel parameter)
15:09karolherbst: AFilius: okay, thanks for testing!
18:54gfxstrand[d]: Ugh... Why is the hardware only ever accepting half of my GS output?
18:54gfxstrand[d]: If the shader outputs 10 vertices, I get 5. If it outputs 100, I get 50
18:57gfxstrand[d]: SPH and state setup is identical
19:00AFilius: Hi, Another question if i may, again on T430+GPU+dock. Tried to suspend to RAM in the dock (with 2 displayport screens attached in dock). (v6.9.9) after resume, 1 of the 2 (identical) screens looked like it has sync/frequency settings issues, (just could barely detect what whas on that screen). xrand didn't show my any unusual at first, but after undock/dock action, the screens acted normally. xrand looked identica
19:01AFilius: xrandr output (DP-2 and DP-3 where reverse order. also Identifier was different. is this a known issue? and perhaps tips how to prevent it? (although undock/dock is already workaround)
19:07gfxstrand[d]: gfxstrand[d]: And it's not an every-other thing. It only takes the first half.
19:08gfxstrand[d]: And it's not control-flow because they're emitted in pairs with no CF between and I'm getting an odd number
19:22gfxstrand[d]: Hrm...
20:14gfxstrand[d]: Figured it out
20:36redsheep[d]: gfxstrand[d]: What was it?
20:42gfxstrand[d]: On Volta+, there is an `out.final` opcode to which you pass the last vertex handle so the hardware knows how many vertices you emitted. pre-Volta, you just leave it in r0 at the end of the shader like you do for fragment shader outputs.
20:43gfxstrand[d]: It's a super easy fix because I already have that infrastructure for fragment shaders. I just had to replace the `OutFinal` with an `OutReg` pre-Volta. It's like a 2-line change in the end.
20:46gfxstrand[d]: But I didn't know that we needed to do that (or had forgotten) so it took me a bit to go "Ah, right. That makes sense."
20:46gfxstrand[d]: I still have no idea what's going wrong with u64 division
21:04redsheep[d]: Ah okay, glad it was a simple fix in the end
21:14redsheep[d]: Are you still running into timeouts due to no reclocking? If I had the hardware it would be fun to watercool one of those old cards so the fans don't matter. It would also be a really simple mod to the card to force the fan on 100%
23:19gfxstrand[d]: I'm not sure. Maybe a couple