02:06gfxstrand[d]: Of course that assumes my GSP survives, which it didn't. :facepalm:
02:10redsheep[d]: I think it is going to be really nice when gsp gets upgraded
02:20gfxstrand[d]: `Pass: 1255814, Crash: 5, Warn: 6, Skip: 1460935, Timeout: 6, Flake: 2, Duration: 45:39, Remaining: 0`
02:42redsheep[d]: is that with your two card setup to speed up cts, or is it actually that much faster now?
03:08gfxstrand[d]: That's with my 2-card setup
03:09gfxstrand[d]: CTS is somewhat GSP-bound because of all the context creation. Having 2 cards means double the GSPs. It also means double the VRAM but IDK which of those two is actually more useful.
03:09gfxstrand[d]: (And no that
03:10gfxstrand[d]: (And no, that's not because we create a context when we enumerate the physical device. That overhead is amortized. It's just because the CTS creates a lot of `VkDevice`s.)
05:59airlied[d]: redsheep[d]: what you think an upgraded GSP brings?
06:03asdqueerfromeu[d]: airlied[d]: ~~Better transit frequency~~ DisplayPort audio support probably
06:05airlied[d]: did we confirm that was a fw bug?
06:07valentineburley[d]: gfxstrand[d]: So that worked for ycbcr.plane_view but breaks most of ycbcr.conversion so we've got a bug somewhere. I messed with the swizzles because that "fixed" the lowering, but I guess that's where the real problem is
06:09asdqueerfromeu[d]: airlied[d]: I'm not sure (but OGK definitely always had working audio in my case)
10:56gfxstrand[d]: valentineburley[d]: If you push the latest version somewhere I'll look in a few hours.
10:58valentineburley[d]: I haven't done anything more than what I pushed to the MR this morning, which is just the swizzles reverted
11:39redsheep[d]: airlied[d]: I think the DP audio issue is reasonably isolated to firmware IIRC. Also, getting better errors was a goal IIUC, as well as the work on GPU stats being in new gsp, right? I suppose wiring up some of that might only happen with nova, but there's been a load of other random oddities that I think might be gsp as well
11:42redsheep[d]: Nvidia folks around here have mentioned a few times that 535 was fairly early on and that things have improved quite a bit
12:23tiredchiku[d]: hang on
12:24tiredchiku[d]: let's just settle this for good
12:32tiredchiku[d]: I'm on arch's kernel 6.10.7 rn
12:32tiredchiku[d]: GSP is 100% loaded: [sidpr@infiltrator nvidia-all]$ sudo dmesg | grep -iE gsp
12:32tiredchiku[d]: [ 4.632518] nouveau 0000:01:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
12:34tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1280868505503399946/PXL_20240904_123336507.TS.mp4?ex=66d9a541&is=66d853c1&hm=b7fa9cc1c28586d16cb48f56e5e542e79d671f7076a7c23e02dbf4a80dc879bf&
12:34tiredchiku[d]: audio plays over DP, but the display does that and resets while audio is playing
12:41tiredchiku[d]: that is 100% not VRR jank either
12:41tiredchiku[d]: because plasma just doesn't detect VRR on this monitor
12:42tiredchiku[d]: when run with nouveau, that is
12:45tiredchiku[d]: now, 535 prop module with GSP enabled
12:45tiredchiku[d]: prop module because it was more feature complete than openrm back then
12:46tiredchiku[d]: redsheep[d]
12:47tiredchiku[d]: and whoever else might've been in the loop for the dp audio bug
12:51karolherbst[d]: tiredchiku[d]: yeah, that needs some kernel code to be added
12:51karolherbst[d]: but the question is also if it's strictly a GSP bug or just nouveau integration stuf
12:52tiredchiku[d]: what exactly is the "DP audio issue"
12:52tiredchiku[d]: because if it is audio not playing over a DP connection on nouveau with GSP enabled...
12:55tiredchiku[d]: I do remember seeing multiple people mention it was broken
12:56redsheep[d]: tiredchiku[d]: The dp audio issue is that for some cards there will be no audio output for displayport connected monitors. I believe there have been mixed reports before, so it working for you is not really surprising
12:56tiredchiku[d]: but since we now have a system where it _works_, I'm less convinced it's a firmware thing and more of a nouveau issue
12:56redsheep[d]: AFAICT some cards just don't output audio on the 535 gsp
12:56tiredchiku[d]: considering how some GA107 cards are entirely busted but the one I have at home boots fine
12:57redsheep[d]: Why does one working card eliminate firmware? If anything I think that makes it more likely to be firmware
12:57tiredchiku[d]: because the firmware is the same across systems
12:57tiredchiku[d]: but what do I know
12:58redsheep[d]: That should mean the kernel side with nouveau is all the right code, I don't think there's any generation dependent audio stuff in nouveau gsp code
12:58redsheep[d]: At that point the card and the firmware it runs are the only factors changing when it is broken
12:59tiredchiku[d]: hm
12:59tiredchiku[d]: makes sense, I suppose
13:01tiredchiku[d]: redsheep[d]: only the card is changing
13:01tiredchiku[d]: isn't the entirety of ampere just like
13:01tiredchiku[d]: one firmware image
13:02redsheep[d]: Hmm I had thought it was unique to the card. Even if it isn't I am sure that internally gsp takes different paths depending on the card it's running on. Also, I am not sure we had a confirmed report of the issue on ampere before, that might just be a working generation.
13:04tiredchiku[d]: ok
13:04tiredchiku[d]: turing is either tu102 fw or tu116
13:05tiredchiku[d]: ampere is either ga100 or ga102
13:05tiredchiku[d]: ada is just ad102
13:07tiredchiku[d]: ugh wait no
13:07tiredchiku[d]: the entirety
13:07tiredchiku[d]: turing, ampere, ada
13:07tiredchiku[d]: is just 2 firmware images
13:07tiredchiku[d]: source: https://github.com/NVIDIA/linux-firmware/commit/f4a3c72e5c413a601d1e21f9606f1c94a610d05d
13:07tiredchiku[d]: only tu102 and ga102 have gsp* imahes
13:08asdqueerfromeu[d]: redsheep[d]: I have a TU117 GPU (and it doesn't work here with nouveau GSP)
13:19tiredchiku[d]: btw
13:20tiredchiku[d]: happy to report that plasma wayland session runs with NOUVEAU_USE_NVK=1 on kernel 6.11-rc5
13:22redsheep[d]: tiredchiku[d]: Don't you mean to test NOUVEAU_USE_ZINK=1?
13:23tiredchiku[d]: ...hm
13:23tiredchiku[d]: heck
13:23tiredchiku[d]: :P
13:23tiredchiku[d]: what 3 months of being away does to a mf
13:23tiredchiku[d]: brb
13:25tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1280881320418869352/image.png?ex=66d9b130&is=66d85fb0&hm=09f0d5404a31c08b33c3fd1a9d9586262f41d71bec6e6eed89b8d0ed352e1126&
13:25tiredchiku[d]: started from a tty
13:25tiredchiku[d]: `NOUVEAU_USE_ZINK=1 startplasma-wayland &2> plasmawayland.log`
13:26redsheep[d]: Do you have your igpu off in bois, just to be certain it is not involved? Also, this is arch I assume?
13:26tiredchiku[d]: iGPU is off, the only connection from monitor to PC is DP straight into the GPU
13:26tiredchiku[d]: and yes, arch
13:27tiredchiku[d]: linux-mainline AUR package (from chaotic-aur because I didn't wanna compile)
13:27tiredchiku[d]: lsof /dev/dri/renderD128 also shows plasmashell
13:27redsheep[d]: Hmm I will have to test that later, that would be nice if that works for me
13:28redsheep[d]: Is it like... smooth? Actually working well?
13:28tiredchiku[d]: yup
13:28tiredchiku[d]: 165 hz
13:28tiredchiku[d]: locked, pretty much
13:29tiredchiku[d]: the 180hz mode doesn't get detected for some reason
13:29tiredchiku[d]: 1440p too
13:29redsheep[d]: How are you reading out that it is running at 165 hz? I haven't been able to find a way to confirm the actual output framerate of the compositor
13:29tiredchiku[d]: monitor OSD
13:30tiredchiku[d]: ok yeah I see how that's flawed
13:30redsheep[d]: That's just the frequency it is driven at, when I have had it run on software rendering and had a compositor framerate of like 4 it would still have said 120hz
13:30tiredchiku[d]: either way, it does visually appear smoother than 60hz
13:30redsheep[d]: That's good
13:30tiredchiku[d]: glxgears segfaults
13:31tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1280882961235054744/Screenshot_20240904_190120.png?ex=66d9b2b7&is=66d86137&hm=c3990934578ce4e388c0e230905e0dbd245f44290fed4ea0a45707fee182f779&
13:31tiredchiku[d]: wait
13:31redsheep[d]: what about wl-gears or something like that
13:31tiredchiku[d]: yeah, looking for that
13:33tiredchiku[d]: eglgears_wayland runs fine
13:33redsheep[d]: tiredchiku[d]: BTW from my testing applications that lock framerate to refresh rate or utilize vsync will still appear to run at the expected framerate in mangohud and all that, even when your display server can only actually output 1 in 40 of the frames. It's really dumb.
13:33tiredchiku[d]: doesn't output framerate info tho
13:33tiredchiku[d]: redsheep[d]: don't think vkcube adheres to refresh rate
13:34tiredchiku[d]: either way
13:34tiredchiku[d]: it's a visually pleasant experience
13:34redsheep[d]: I mean it is doing so in that image 🤷
13:34redsheep[d]: Regardless if it looks smooth things are probably working
13:34tiredchiku[d]: yeah
13:35tiredchiku[d]: still poking around kwin debug console too
13:36tiredchiku[d]: too easy
13:36tiredchiku[d]: kwin is running at 165 fps confirmed
13:36redsheep[d]: Wonder why glxgears would segfault, can you get other xwayland applications running?
13:36tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1280884225402339530/Screenshot_20240904_190628.png?ex=66d9b3e5&is=66d86265&hm=6c94d2d780b4cf303e0f19fe2357b6e059010c035d5cdfc518fb8a6698f9e7bc&
13:37tiredchiku[d]: redsheep[d]: eglgears_x11 runs fine
13:37tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1280884567590440981/PXL_20240904_133718942.MP.jpg?ex=66d9b436&is=66d862b6&hm=a15dd8a3b33b60219cd5bc5e7831a9ae4181d6f0f1186be59219d26750425fb7&
13:38tiredchiku[d]: something something rounding error
13:38tiredchiku[d]: but yeah
13:38redsheep[d]: That is good to know, would have helped quite a lot when testing before... Yeah looks good
13:39tiredchiku[d]: anything else you want me to check before I boot out of this USB install for the day?
13:40redsheep[d]: Probably good to check if the plasma x11 session works well too, and that glxgears doesn't segfault on an x11 session?
13:40tiredchiku[d]: on it
13:43tiredchiku[d]: plasma x11 appears to be a no-go
13:43tiredchiku[d]: driver from the future, truly
13:44tiredchiku[d]: blank screen w/ cursor
13:46tiredchiku[d]: will grab logs tomorrow
13:46redsheep[d]: ... Text cursor, or mouse cursor?
13:47tiredchiku[d]: mouse
13:48redsheep[d]: That's bizarre, that's exactly what wayland has done the entire time I have been testing it... somehow inverted the test results
13:48tiredchiku[d]: takeaways from today:
13:48tiredchiku[d]: - I seemingly have DP audio working
13:48tiredchiku[d]: - Plasma Wayland works with Zink on kernel 6.11
13:48tiredchiku[d]: - Plasma X11 does not work with Zink on kernel 6.11
13:49redsheep[d]: I bet the glxgears segfault is related to your broken x11 session
13:49redsheep[d]: That's so weird
13:49tiredchiku[d]: eglgears_x11 works tho
13:49redsheep[d]: Right, even more weird
13:49magic_rb[d]: Do you happen to know if mesa master works with 6.9? Its the newest i can go with linux
13:50tiredchiku[d]: tomorrow I'll get back to testing games on nvk
13:50tiredchiku[d]: magic_rb[d]: no idea, sadly
13:51magic_rb[d]: Guess ill find iut once the build finishes
13:51tiredchiku[d]: tiredchiku[d]: quite excited to try throwing Alan Wake 2 at Mary's MR
14:07marysaka[d]: tiredchiku[d]: I have a feeling it's going to just tell you it's not supported as I don't expose task shaders
14:08tiredchiku[d]: there should still be a minor perf difference between with-MR and without-MR, no?
14:11marysaka[d]: not sure :AkkoShrug:
14:11tiredchiku[d]: well
14:11tiredchiku[d]: only one way to find out
14:11tiredchiku[d]: :wolfFIRE:
15:06gfxstrand[d]: valentineburley[d]: I think we're getting closer but it's still affecting lowering somehow and I have no idea how.
15:06gfxstrand[d]: Oh...
15:11gfxstrand[d]: It's `chroma_range()` in `vk_nir_convert_ycbcr.c`. The narrowing tries to turn the 10 or 12-bit into 8-bit by undoing the 10 or 12-bit UNORM and then manually doing an 8-bit unorm(ish) thing. When we use a 16-bit UNORM format but think that it's 10 or 12-bit in the lowering, it doesn't narrow correctly.
16:46gfxstrand[d]: karolherbst[d]: Do we know exactly how the CT_SELECT packet works? Like, what's the mapping? Right now, we just set it to 0, 1, 2, 3, 4, 5, 6, 7 and set the number of color targets.
16:46gfxstrand[d]: In particular, does it map bindings to shader locations or shader locations to bindings?
16:47karolherbst[d]: mhhhh... I don't think anybody really knows as I suspect this was simply copied
16:47karolherbst[d]: it's 121c, right?
16:47gfxstrand[d]: I think VK_KHR_dynamic_rendering_local_read is literally just a matter of emitting that packet. 😁
16:48karolherbst[d]: mhh, let's see if the gl driver does anything with it
16:48karolherbst[d]: it seems to do btw
16:49karolherbst[d]: mhhh..
16:49karolherbst[d]: ehh wait...
16:49karolherbst[d]: huh
16:50karolherbst[d]: at least gl calls it RT_CONTROL for rendertarget I guess
16:50karolherbst[d]: but it's only setting it to 1
16:50karolherbst[d]: ehh and 076543210
16:51karolherbst[d]: yeah nevermind, the gl driver doesn't do anything with it
16:51gfxstrand[d]: Yeah, that's what I figured.
17:22valentineburley[d]: gfxstrand[d]: So the thing is I hardcoded the bpcs now as 10 and it's all working
17:24valentineburley[d]: Yeah the problem was that bpcs0 was 6
17:26valentineburley[d]: Test case 'dEQP-VK.ycbcr.conversion.g10x6_b10x6r10x6_2plane_444_unorm_3pack16.ycbcr_709.itu_narrow.nearest_tiling_linear_binding_15'..
17:26valentineburley[d]: bpcs[0]: 6
17:26valentineburley[d]: bpcs[1]: 10
17:26valentineburley[d]: bpcs[2]: 10
17:26valentineburley[d]: Fail (Result comparison failed)
17:27valentineburley[d]: (This is on the branch I pushed earlier)
17:29valentineburley[d]: The math works well enough for 10, that's always worked on Turnip too
17:30valentineburley[d]: But our channels and/or swizzles aren't lined up properly still, and I don't know what a clean solution could be
19:34magic_rb[d]: Hey so i am trying to get a working laptop here, nvidia proprietary has a lot of funny issues, but that belongs somewhere else
19:35magic_rb[d]: On nouveau i end up with this fun problem if i attempt to enable a external nvidia connected monitor through thunderbolt 4
19:35magic_rb[d]: https://termbin.com/64cy/
19:35magic_rb[d]: Kernel 6.9.12 mesa 24.2.1 on a laptop 3060
20:13tiredchiku[d]: what distro is that on? nix?
20:47valentineburley[d]: gfxstrand[d]: I haven't tested it on NVK yet and I won't get to until tomorrow, but this should fix the bits per channel reading
20:47valentineburley[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30821/diffs?commit_id=b3d9802e90603ef72e44d17312097886b40e208d
20:55magic_rb[d]: tiredchiku[d]: Yep
20:55magic_rb[d]: Zfs 2.2.6 dropped ill try 6.10 but i doubt itll do anything
20:55magic_rb[d]: On nvidia proprietary i cannot open anything on the dGPU without the external displays freezing. Known bug for a year or so
20:59gfxstrand[d]: valentineburley[d]: Ah, yeah. That'll do it.
21:00valentineburley[d]: I have to move the continue before ycbcr_comp[ycbcr_component] still, but I'll fix that tomorrow too
21:00gfxstrand[d]: `dEQP-VK.ycbcr.conversion.*` all pass on NVK with that branch now.
21:00gfxstrand[d]: I'll run the rest just to be sure.
21:04valentineburley[d]: Great, thanks!
21:06valentineburley[d]: I can check the other drivers during the weekend at the latest, but could I ask either you or maybe Konstantin to look into lavapipe?
21:08valentineburley[d]: That might be a bit too deep of a rabbit hole for me to dive into
21:09gfxstrand[d]: Yeah, I can give it a quick look.
21:10gfxstrand[d]: Honestly, LVP may "just work"
21:10gfxstrand[d]: I can probably also throw together an ANV patch
21:10gfxstrand[d]: IDK if ANV uses those helpers, though. Maybe it's already okay?
21:10magic_rb[d]: magic_rb[d]: okay 6.10 works, im pinning everything for the next year, i dont have time to mess with things again
21:11valentineburley[d]: gfxstrand[d]: It does not 😄
21:11gfxstrand[d]: gfxstrand[d]: valentineburley[d] `dEQP-VK.ycbcr.*` passes on NVK
21:11valentineburley[d]: Awesome
21:12valentineburley[d]: I don't think Anv is affected here at all
21:12gfxstrand[d]: Yeah, it doesn't use `vk_format_to_pipe_format()` or whatever it's called.
21:16gfxstrand[d]: valentineburley[d]: It seems to work for me. That or my scripts are failing me.
21:16gfxstrand[d]: CTS says I ran lavapipe
21:18gfxstrand[d]: Running ANV now and I think I might have seen some fails
21:19gfxstrand[d]: ANV passes, too
21:24valentineburley[d]: LVP on this branch for me fails 96/800 of `dEQP-VK.ycbcr.conversion.g10x6_b10x6r10x6*`, with the `vk_format_to_pipe_format` change reverted 96/800 passes
21:24valentineburley[d]: ¯\_(ツ)_/¯
21:28valentineburley[d]: valentineburley[d]: fixed
21:29gfxstrand[d]: Test run totals:
21:29gfxstrand[d]: Passed: 96/800 (12.0%)
21:29gfxstrand[d]: Failed: 0/800 (0.0%)
21:29gfxstrand[d]: Not supported: 704/800 (88.0%)
21:29gfxstrand[d]: Warnings: 0/800 (0.0%)
21:29gfxstrand[d]: Waived: 0/800 (0.0%)
21:29valentineburley[d]: interesting
21:30gfxstrand[d]: Confirmed that it's running the branch I thought it was.
21:31gfxstrand[d]: I'm on LLVM 18.1.6
21:31valentineburley[d]: I'm on aarch64, would that matter?
21:31gfxstrand[d]: It very well could if there's some weird little rounding difference
21:31valentineburley[d]: Hm
21:36valentineburley[d]: It also fails on my desktop
21:37valentineburley[d]: Other formats work, so I don't know what's going on here
22:01valentineburley[d]: gfxstrand[d]: lavapipe's also failing in CI: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/63186261
22:01valentineburley[d]: Assertion `swizzle[j] < 4' failed.
22:01valentineburley[d]: that's not good
22:01gfxstrand[d]: Wait, what?
22:02gfxstrand[d]: Oh, it's rendering to it and tripping up on the X's
22:02valentineburley[d]: yeah
22:03valentineburley[d]: Anyway I'm off for today, thanks for the help!
22:03gfxstrand[d]: yw