13:50 AndrewR: karolherbst, thanks for looking into "my" bugs!
13:53 karolherbst: no problem
16:18 fdobridge: <g​fxstrand> @airlied What branches/patches do I need to cobble together to get this supposedly working GSP?
17:08 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I might try to do that
18:08 fdobridge: <a​irlied> https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/nouveau-fw-535.113.01?ref_type=heads
18:09 fdobridge: <a​irlied> https://copr.fedorainfracloud.org/coprs/airlied/nouveau-gsp/
18:10 fdobridge: <a​irlied> Find the nvidia-gpu-firmware rpm for your distro from the copr
18:10 fdobridge: <a​irlied> You might have to downgrade the installed one
18:17 fdobridge: <a​irlied> @gfxstrand there may be some regressions vs non gsp, but let me know
19:10 fdobridge: <a​irlied> I should probably rebase the copr to avoid downgradeling
19:19 fdobridge: <g​fxstrand> @airlied doesn't build...
19:20 fdobridge: <a​irlied> Hmm missing file or something?
19:20 fdobridge: <g​fxstrand> ```
19:20 fdobridge: <g​fxstrand> drivers/usb/typec/altmodes/displayport.c: In function ‘dp_altmode_vdm’:
19:20 fdobridge: <g​fxstrand> drivers/usb/typec/altmodes/displayport.c:309:33: error: too few arguments to function ‘drm_connector_oob_hotplug_event’
19:20 fdobridge: <g​fxstrand> 309 | drm_connector_oob_hotplug_event(dp->connector_fwnode);
19:20 fdobridge: <g​fxstrand> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
19:20 fdobridge: <g​fxstrand> In file included from drivers/usb/typec/altmodes/displayport.c:17:
19:20 fdobridge: <g​fxstrand> ./include/drm/drm_connector.h:1984:6: note: declared here
19:20 fdobridge: <g​fxstrand> 1984 | void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
19:20 fdobridge: <g​fxstrand> ```
19:24 fdobridge: <g​fxstrand> I think I typed an okay fix
19:24 fdobridge: <a​irlied> ah missing fix, I threw it on the branch
19:25 fdobridge: <a​irlied> it's already in drm-next so just never landed it elsewhere
19:40 fdobridge: <k​arolherbst🐧🦀> the timer resolution on nvidia is 1000ns, right?
19:43 fdobridge: <g​fxstrand> ```
19:43 fdobridge: <g​fxstrand> grub2-mkrelpath: error: failed to get canonical path of `/boot/vmlinuz-6.6.0-rc7-nvk-uapi+'.
19:43 fdobridge: <g​fxstrand> ```
19:43 fdobridge: <a​irlied> you going to make me install f39 aren't you
19:48 fdobridge: <g​fxstrand> IDK
19:48 fdobridge: <g​fxstrand> Oh, I should really be using an f39 config for this, shouldn't i?
19:49 fdobridge: <a​irlied> I've kicked off an update on one laptop, it might be grub2 bug
19:51 fdobridge: <g​fxstrand> I was running out of space on /boot so that might have had something to do with it.
19:51 fdobridge: <k​arolherbst🐧🦀> the eternal pain of /boot
19:54 fdobridge: <g​fxstrand> You made me install f39. 😛
19:55 fdobridge: <a​irlied> ah yes not enough /boot will do bad thins
19:55 fdobridge: <a​irlied> things
19:59 fdobridge: <m​arysaka> nice reminder that I need to update all my fedora installs this week-end :vReiAgony:
20:02 fdobridge: <a​irlied> @gfxstrand then you need to boot with nouveau.config=NvGspRm=1
20:02 fdobridge: <a​irlied> if you are I assume not on Ada
20:03 fdobridge: <m​arysaka> did the Ampere display issue got fixed?
20:04 fdobridge: <a​irlied> there's an ampere display issue?
20:06 fdobridge: <g​fxstrand> Yeah, IDK what's going wrong with kernel installs
20:06 fdobridge: <m​arysaka> yeah without this commented out the display init doesn't work https://gitlab.freedesktop.org/skeggsb/nouveau/-/commit/3b0b5f211852a86c5f539b4e4ec91e36927dc031#7a34141ffa70af07a2d14b7dedf8d3864519a0bc_65_73
20:07 fdobridge: <g​fxstrand> It's not copying vmlinuz to /boot
20:08 fdobridge: <m​arysaka> I may have forgot to report it properly, if you want me to post it on some tracker let me know @airlied
20:09 fdobridge: <a​irlied> doesn't work with GSP?
20:10 fdobridge: <a​irlied> https://gitlab.freedesktop.org/drm/nouveau/-/issues is probably a place to go
20:12 fdobridge: <g​fxstrand> Yeah, `/usr/bin/install-kernel` is somehow busted
20:14 fdobridge: <g​fxstrand> And it's a binary so I can't easily debug it
20:14 fdobridge: <a​irlied> just building a kernel now so will see in a minute and escalate if I can reproduce
20:15 fdobridge: <g​fxstrand> Of course it's part of the systemd package. 🤦🏻‍♀️
20:26 fdobridge: <a​irlied> okay something is install bzImage instead of vmlinuz
20:26 fdobridge: <a​irlied> fml
20:33 fdobridge: <g​fxstrand> 🍿
20:36 fdobridge: <k​arolherbst🐧🦀> oh no.. now that NAK actually lands, I don't have a good excuse for ignoring rusticl bugs on nouveau anymore :ferrisCluelesser:
20:37 fdobridge: <a​irlied> okay I've done what I'm best at, escalating it to a mailing list, I'll probably debug it for real later
20:37 fdobridge: <a​irlied> @karolherbst just ask for function calls 😛
20:37 fdobridge: <k​arolherbst🐧🦀> Faith.....
20:37 fdobridge: <k​arolherbst🐧🦀> 😄
20:38 fdobridge: <k​arolherbst🐧🦀> but anyway
20:38 fdobridge: <k​arolherbst🐧🦀> rusticl on nvc0 ain't _that_ bad
20:38 fdobridge: <k​arolherbst🐧🦀> though it throws bunch of `PUSH_NOT_ENOUGH_DATA`
20:38 fdobridge: <k​arolherbst🐧🦀> but that could be my fault flushing in a cursed way on unused queues or something
20:39 fdobridge: <k​arolherbst🐧🦀> though even then it shouldn't matter as we still emit the fence...
20:39 fdobridge: <k​arolherbst🐧🦀> probably some driver bug
20:48 fdobridge: <g​fxstrand> Uh, IDK that you want to make nvc0 use NAK
20:52 fdobridge: <k​arolherbst🐧🦀> mostly for CL, but then again.. maybe we just want a new driver
20:53 fdobridge: <g​fxstrand> Yeah, IDK.
20:53 fdobridge: <k​arolherbst🐧🦀> or maybe it's just zink 😄
20:54 fdobridge: <k​arolherbst🐧🦀> might want to give it a go on nvk
20:54 fdobridge: <k​arolherbst🐧🦀> but I'd need `float_controls`
20:54 fdobridge: <k​arolherbst🐧🦀> for correctness
21:20 fdobridge: <k​arolherbst🐧🦀> `Pass 1995 Fails 309 Crashes 150 Timeouts 0: 100%` I think that's not tooooo bad
21:21 fdobridge: <k​arolherbst🐧🦀> 100 fails are like conversion nonsense
21:21 fdobridge: <k​arolherbst🐧🦀> 8/16 bit stuff is just broken and I don't know if I have the 🥄 to fix xodegen
21:21 fdobridge: <k​arolherbst🐧🦀> *codegen
21:28 fdobridge:<g​fxstrand> plugs in a kepler
21:30 fdobridge: <g​fxstrand> ```
21:30 fdobridge: <g​fxstrand> crucible: info : ran 1000 tests
21:30 fdobridge: <g​fxstrand> crucible: info : pass 491
21:30 fdobridge: <g​fxstrand> crucible: info : fail 509
21:30 fdobridge: <g​fxstrand> crucible: info : skip 0
21:30 fdobridge: <g​fxstrand> crucible: info : lost 0
21:30 fdobridge: <g​fxstrand> ```
21:30 fdobridge: <g​fxstrand> Off to a good start. 😅
21:31 fdobridge: <k​arolherbst🐧🦀> prolly something silly 😄
21:33 fdobridge: <g​fxstrand> Oh, my image layout code doesn't work right on Kepler. Probably some alignment thing that's different.
21:41 fdobridge: <g​fxstrand> ```
21:41 fdobridge: <g​fxstrand> crucible: info : ran 1000 tests
21:41 fdobridge: <g​fxstrand> crucible: info : pass 1000
21:41 fdobridge: <g​fxstrand> crucible: info : fail 0
21:41 fdobridge: <g​fxstrand> crucible: info : skip 0
21:41 fdobridge: <g​fxstrand> crucible: info : lost 0
21:41 fdobridge: <g​fxstrand> ```
21:41 fdobridge: <g​fxstrand> Nothing wrong with image layouts. Kepler just tiles funny
21:42 fdobridge: <g​fxstrand> My tests were asserting that (0, 0) is always at the first byte in the tile which isn't true on Kepler
21:42 fdobridge: <o​rowith2os> depending on the size of the patch, one could argue that it was "only an x line patch" that went from 50% fails to 100% passes :v
21:43 fdobridge: <g​fxstrand> Good to know that the tiling changed, though. That'll come in handy for VK_EXT_host_copy
21:43 fdobridge: <g​fxstrand> Good to know that the tiling changed, though. That'll come in handy for VK_EXT_host_image_copy (edited)
21:51 fdobridge: <g​fxstrand> Looks like something's wrong with the instruction heap. That or I've got an alignment off somewhere
21:52 fdobridge: <k​arolherbst🐧🦀> first instruction needs to be 0x80 aligned
21:53 fdobridge: <k​arolherbst🐧🦀> but that should be the same on later gens until turing
21:58 fdobridge: <k​arolherbst🐧🦀> @gfxstrand ohh before you go crazy on debugging: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25997/diffs?commit_id=84b086d994d18a24bed01a5094cba02ea1316cd2
21:58 fdobridge: <k​arolherbst🐧🦀> might want to land that from that MR asap 😄
22:04 fdobridge: <g​fxstrand> Yeah, we're not landing that
22:04 fdobridge: <g​fxstrand> Oh, that one patch? Yeah.
22:05 fdobridge: <k​arolherbst🐧🦀> yeah...
22:05 fdobridge: <k​arolherbst🐧🦀> just that one patch
22:05 fdobridge: <k​arolherbst🐧🦀> 😄
22:09 fdobridge: <g​fxstrand> Something is wrong on kepler with shader caching
22:09 fdobridge: <g​fxstrand> Or alignments
22:12 fdobridge: <k​arolherbst🐧🦀> what's the error you are seeing?
22:23 fdobridge: <g​fxstrand> faults
22:24 fdobridge: <g​fxstrand> But it depends on shader address and other shaders uploaded previously
22:24 fdobridge: <g​fxstrand> it's fun like that
22:30 fdobridge: <k​arolherbst🐧🦀> sounds annoying
22:30 fdobridge: <g​fxstrand> Okay, if my shader is uploaded at 0xff00, it's fine. At 0xfb00, it breaks
22:30 fdobridge: <k​arolherbst🐧🦀> huh?
22:31 fdobridge: <k​arolherbst🐧🦀> is that the first instruction or the header?
22:31 fdobridge: <g​fxstrand> uh... header?
22:31 fdobridge: <g​fxstrand> Oh, this is compute. No headers
22:31 fdobridge: <k​arolherbst🐧🦀> well that would be invalid
22:31 fdobridge: <k​arolherbst🐧🦀> ahhh
22:31 fdobridge: <k​arolherbst🐧🦀> okay
22:31 fdobridge: <k​arolherbst🐧🦀> for compute it's fine...
22:32 fdobridge: <k​arolherbst🐧🦀> hope it's not some cache invalidation stuff or something...
22:32 fdobridge: <k​arolherbst🐧🦀> but normally if there is an error the hardware complains loudly before executing the code
22:34 fdobridge: <g​fxstrand> Hrm... My error depends on where it's located... WTH?!?
22:34 fdobridge: <g​fxstrand> Now I'm getting OOR_ADDR instead of a fault
22:36 fdobridge: <k​arolherbst🐧🦀> mhhh
22:36 fdobridge: <k​arolherbst🐧🦀> maybe something up with the descriptors?
22:37 fdobridge: <k​arolherbst🐧🦀> `OOR_ADDR` is I think an out of rance access on non global storage
22:37 fdobridge: <k​arolherbst🐧🦀> maybe also on input/output stuff
22:37 fdobridge: <k​arolherbst🐧🦀> but it's compute, soo...
22:38 fdobridge: <g​fxstrand> The error I get changes as I move the shader around
22:38 fdobridge: <g​fxstrand> Something funky is going on
22:38 fdobridge: <k​arolherbst🐧🦀> yeah.. sounds like it
22:38 fdobridge: <k​arolherbst🐧🦀> maybe the QMD is busted?
22:38 fdobridge: <g​fxstrand> Seems plausible
22:38 fdobridge: <g​fxstrand> But I suspect it's something else because apparently vkcube is busted
22:38 fdobridge: <k​arolherbst🐧🦀> pain
22:38 fdobridge: <g​fxstrand> but QMDs are a real possibility, too.
22:38 fdobridge: <g​fxstrand> I'll look more tomorrow
23:20 fdobridge: <a​irlied> @gfxstrand https://bugzilla.redhat.com/show_bug.cgi?id=2239008 is the bug
23:21 fdobridge: <a​irlied> looks like updates-testing might have the fix, will test when I get back home