IRC Logs of #nouveau on irc.freenode.net for 2024-05-10

03:13 fdobridge: <rinlovesyou> had to disable the compositor but damn it feels awesome running a desktop session on zink
03:13 fdobridge: <rinlovesyou> https://cdn.discordapp.com/attachments/1034184951790305330/1238327921483972629/image.png?ex=663ee23f&is=663d90bf&hm=e773e26e86d7b8cf0912eb11841b65063edd61a54acd0fba8431412693286331&
03:49 fdobridge: <redsheep> I didn't have to disable the compositor... That shows a different kernel from Faith's special branch, is it just listing the wrong kernel?
03:50 fdobridge: <rinlovesyou> No that's just a normal kernel
03:51 fdobridge: <rinlovesyou> Works great with the compositor off, Wayland doesn't start though
04:09 fdobridge: <airlied> @skeggsb9778 do you have any clue on why https://lore.kernel.org/nouveau/20240426154138.64643-1-lyude@redhat.com/ would regression acr/sec boot?
04:10 fdobridge: <airlied> I'm not really sure where the stuff loaded into the dma map is eventually used on the gpu side
04:13 fdobridge: <skeggsb9778> @airlied no. i did take a look earlier, and tried to reproduce (though, on ampere), and it works fine here
04:13 fdobridge: <airlied> gsp works for me on turing, non-gsp paths explode
04:14 fdobridge: <airlied> I'll just revert it for now and try to figure it out later I think
04:14 fdobridge: <skeggsb9778> i tried ampere for non-gsp (i've only got ampere and ada boards now), and it was fine here
04:14 fdobridge: <skeggsb9778> we can try and debug it if you can reproduce at least
04:15 fdobridge: <skeggsb9778> i was trying on top of the patch series i sent though, but i really can't see that making any difference
04:15 fdobridge: <airlied> I think the different sec/acr loading paths on ampere might make a difference
04:16 fdobridge: <skeggsb9778> *tries* to page back in how ACR works 😛
04:16 fdobridge: <airlied> or rather the different falcon paths
04:16 fdobridge: <skeggsb9778> does /me work here?
04:16 fdobridge:<airlied> checks
04:16 fdobridge: <skeggsb9778> it appears so 😛
04:17 fdobridge: <airlied> the dma paths seem to be different on falcon pre-ga102 and post
04:17 fdobridge: <skeggsb9778> yes, i think ampere is when the boot-from-hs stuff got added
04:18 fdobridge: <skeggsb9778> (so no more bootloader)
04:18 fdobridge: <airlied> but I'm having trouble working out where the dma_addr ends up being used, I assume some page table in instmem is pointing to it, and then we poke the falcon with the instmem address
04:18 fdobridge: <airlied> though I still get a dma address that is 32-bit
04:18 fdobridge: <airlied> the other option is some missing dma sync, but I added a few and didn't seem to help
04:19 fdobridge: <skeggsb9778> i was going to try if changing from DMA_TO_DEVICE to DMA_BIDIRECTIONAL would help, if i could reprod here
04:20 fdobridge: <airlied> did that, didn't help, also stuck a sync_single after writing the signatures
04:20 fdobridge: <skeggsb9778> i was going to see if changing from DMA_TO_DEVICE to DMA_BIDIRECTIONAL would help, if i could reprod here (edited)
04:20 fdobridge: <skeggsb9778> ugh
04:37 fdobridge: <skeggsb9778> what happens if you make nvkm_firmware_mem_target() unconditionally return NVKM_MEM_TARGET_NCOH?
04:37 fdobridge: <skeggsb9778> (instead of just for tegra)
05:12 HdkR: Does Orin need GSP, or is this a desktop only feature? I'm not familiar with the whole falcon/riscv shenanigans on Tegra
05:13 HdkR: Not that I need it today since I'm not using the integrated GPU on the platform
05:19 fdobridge: <airlied> desktop only feature
05:20 fdobridge: <airlied> orin also needs a bunch of nouveau enablement if it was going to work
05:23 HdkR: Nice, I was aware that Host1x support needs a lot of work, wasn't sure if it needed GSP :)
05:23 HdkR: Hopefully Thor won't be troublesome either
05:37 fdobridge: <airlied> oh I think it needs work beyond host1x, don't think we have any official info on anything past orin
05:38 fdobridge: <airlied> seems to blow up worse 😛 gets a hub fault
05:39 fdobridge: <skeggsb9778> where does it happen in that case?
05:40 fdobridge: <airlied> [ 9.405131] nouveau 0000:01:00.0: sec2(acr):AHESASC: booting
05:42 HdkR: Only information I have for Thor is that the CPU cores are going to be Neoverse-V3AE and I want to get my grubby fingers on them :)
05:46 fdobridge: <airlied> oh the fault might have been me being over zealous with NCOHs but just doing one, gets a timeout
06:18 manav: Greetings everyone! I'm Manav, a 3rd year Computer Science student from India and I have an aim of working at CERN Labs one day where I can contribute to a place that drives scientific innovation where my interest lies in the domain of system/low-level as I have always been fascinated by the core or the internals of Computer Science. My research in gaining more experience in this field lead me to to the mentorship program of X.org -
06:18 manav: <manav> Endless Vacation of Code where I found a problem statement named 'Instruction Scheduler' where the task is to write an instruction scheduling pass for basic blocks in the nouveau codegen compiler and to create scheduling policies that improve performance. Some resources and guidance regarding this problem statement will be a huge help and I will forever be grateful, thank you!
15:02 fdobridge: <gfxstrand> Don't worry about bothering me. I really appreciate the testing. For getting to the bottom of it, though, I think I need to install KWin on my desktop and play around.
15:03 fdobridge: <gfxstrand> For the MSAA thing, IDK what's going on there. That's probably a separate investigation. Today, I think I'm more interested in figuring out why KWin Wayland doesn't work.
15:13 fdobridge: <redsheep> Sounds good, hopefully it's not too bad. It's not great that it doesn't seem to throw out any errors now that the invalid modifier workaround is in place
15:13 fdobridge: <gfxstrand> Can I install just kwin? Will that work?
15:14 fdobridge: <Sid> it does work, yes
15:14 fdobridge: <redsheep> I wonder if any kwin developers are in the irc or discord and could comment on whether it should even hit that path
15:14 fdobridge: <Sid> you can run kwin outside of plasma
15:14 fdobridge: <Sid> I'm also sitting down to do my bit of testing now, trying to get some logs
15:14 fdobridge: <gfxstrand> I need to figure out what path it's hitting first
15:14 fdobridge: <Sid> kwin, sway, i3, mutter
15:15 fdobridge: <Sid> though, my experience may not resemble the state of things accurately since I'm rendering to the laptop display using DRI_PRIME shenanigans
15:15 fdobridge: <Sid> because of a lack of a mux switch or an external display
15:15 fdobridge: <gfxstrand> For the MSAA thing, I suspect it's some sort of barrier issue with resolves in Zink but I'm not sure as I haven't fully triaged it yet.
15:16 fdobridge: <gfxstrand> How do I start kwin from the command line?
15:16 fdobridge: <Sid> on arch at least, it's just kwin_x11 or kwin_wayland
15:17 fdobridge: <Sid> ```
15:17 fdobridge: <Sid> [sidpr@constructor documents]$ ls /usr/bin/kwin*
15:17 fdobridge: <Sid> /usr/bin/kwin_wayland /usr/bin/kwin_wayland_wrapper /usr/bin/kwin_x11
15:17 fdobridge: <Sid> ```
15:17 fdobridge: <redsheep> That sounds accurate. Maybe it's not even an msaa issue, but just something that's exposed by the extra load it creates on that part of the hardware
15:17 fdobridge: <Sid> though, it does render only a black screen and a cursor on both
15:17 fdobridge: <Sid> afaik
15:19 fdobridge: <redsheep> A black screen and cursor is unfortunately the end state for me when it's broken, so if that's where you end up with kwin wayland alone that might not be so useful as a test
15:20 fdobridge: <gfxstrand> I get a black screen with nouveau GL as well
15:20 fdobridge: <Sid> ..right, I have to reboot between tests .-.
15:20 fdobridge: <gfxstrand> Maybe I need to connect an app to it
15:22 fdobridge: <Sid> apologies to my friends on IRC for my next few messages
15:25 fdobridge: <gfxstrand> kwin seems to work here
15:25 fdobridge: <gfxstrand> I can start it up and display the gears demo
15:26 fdobridge: <redsheep> Is this on your laptop?
15:26 fdobridge: <gfxstrand> Desktop
15:26 fdobridge: <gfxstrand> 3060 is the only GPU in the machine
15:27 fdobridge: <gfxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1238512851442733069/image.png?ex=663f8e7a&is=663e3cfa&hm=3cf84bf679b001ade84639bf4f5c1b742360b27b6fc151c68f545223643b5980&
15:28 fdobridge: <redsheep> And this is kwin wayland? How do you get an app to load? I can try to do an equivalent test
15:29 fdobridge: <Sid> here's what I'm seeing:
15:29 fdobridge: <Sid>
15:29 fdobridge: <Sid> `DRI_PRIME=pci-0000_01_00_0 startx /usr/bin/startplasma-x11` results in a plasma session that crashes and restarts every second
15:29 fdobridge: <Sid> `DRI_PRIME=pci-0000_01_00_0 NOUVEAU_USE_ZINK=1 startx /usr/bin/startplasma-x11` results in a plasma session on the iGPU, completely ignoring prime offload
15:29 fdobridge: <Sid> `DRI_PRIME=pci-0000_01_00_0 MESA_LOADER_DRIVER_OVERRIDE=zink startx /usr/bin/startplasma-x11` results in eglCreateImageKHR not supported
15:29 fdobridge: <Sid>
15:29 fdobridge: <Sid> `DRI_PRIME=pci-0000_01_00_0 /usr/bin/startplasma-wayland` results in a usable wayland session rendering with nvc0 and being presented over the iGPU
15:29 fdobridge: <Sid> `DRI_PRIME=pci-0000_01_00_0 MESA_LOADER_DRIVER_OVERRIDE=zink /usr/bin/startplasma-wayland` results in a black screen with a cursor
15:30 fdobridge: <gfxstrand> This is all with the latest branch as of yesterday?
15:30 fdobridge: <Sid> `DRI_PRIME=pci-0000_01_00_0 NOUVEAU_USE_ZINK=1 /usr/bin/startplasma-wayland` has identical behavior to its X11 counterpart
15:31 fdobridge: <Sid> I believe my build is a few days older with the modifiers MR, as well as the kernel being a few days old (your NVK branch)
15:31 fdobridge: <Sid> I can update everything to current state and try again
15:31 fdobridge: <Sid> probably should do that
15:31 fdobridge: <redsheep> Yeah most of that sounds like some of my older results, though still some weird stuff
15:32 fdobridge: <Sid> again, my rendering setup isn't standard either. I don't have access to an external display to test with until wednesday
15:32 fdobridge: <Sid> I *could* set up a VFIO passthrough'd VM and test on that, get output over Looking Glass
15:33 fdobridge: <gfxstrand> Yeah, I could believe rendering on NV and displaying on Intel could get funky. If you're more than about a day out of date, though, that could be the issue.
15:33 fdobridge: <Sid> updating my local copies of both your kernel and mesa
15:33 fdobridge: <Sid> will update everything and try again
15:34 fdobridge: <Sid> then move on to gnome
15:34 fdobridge: <gfxstrand> 👍🏻
15:34 fdobridge: <Sid> and end with sway/i3
15:34 fdobridge: <gfxstrand> GNOME seems to work okay here
15:34 fdobridge: <Sid> I'm particularly interested in seeing how Sway's Vulkan renderer behaves
15:34 fdobridge: <Sid> I don't know any other wlroots based compositors that expose wlroots' vulkan renderer
15:35 bl4ckb0ne: they just need to usr WLR_RENDERER=vulkan if they use the autocreate renderer func
15:35 bl4ckb0ne: most of them do, a few compositors are explicitly creating a gles2 renderer (wayfire and hyprland mostly)
15:36 fdobridge: <Sid> I see
15:36 bl4ckb0ne: if you dont want to bother with a full on compositor we have tinywl https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master/tinywl
15:36 bl4ckb0ne: which is our minimum viable compositor
15:37 fdobridge: <Sid> I main sway and i3 already, so that's not a problem
15:37 fdobridge: <Sid> would've appreciated something like tinywl for gnome and plasma, but I did get extremely minimal desktop sessions installed, so, also fine
15:37 bl4ckb0ne: there's #wlroots on libera if you need any insight on the code
15:43 fdobridge: <Sid> sadly gitlab.freedesktop.org is being mean and giving me terrible access speeds
15:43 fdobridge: <redsheep> I suppose it might also be useful at some point for me to enable my AMD iGPU again and troubleshoot all the stuff that would break, ideally amd+nvidia setups should be made to work smoothly. I don't really think any of that is really likely to be an NVK issue, but it affects NVK if we're defaulting zink. It seems to just really confuse the driver loader stuff.
15:43 fdobridge: <Sid> 20KB/s download despite me having 500mbps internet right now
15:43 bl4ckb0ne: spambots keeping us from having nice things
15:44 fdobridge: <Sid> I feel like there should be a readonly mirror of our git instance somewhere
15:44 fdobridge: <Sid> so that people who just want to clone sources can do so without much pain
15:44 fdobridge: <Sid> because this kernel repo is *big*
15:45 fdobridge: <gfxstrand> Ugh, yeah, kernels...
15:47 fdobridge: <mohamexiety> wait you dont need all of it
15:47 fdobridge: <Sid> yeah
15:47 fdobridge: <Sid> --depth=1 to the rescue
15:47 fdobridge: <mohamexiety> clone the single branch and only the latest commit
15:47 fdobridge: <mohamexiety> yep
15:47 fdobridge: <Sid> but 20KB/s is still slow
15:47 fdobridge: <mohamexiety> try cloudflare WARP
15:48 fdobridge: <mohamexiety> I had a weird issue where I was getting really bad routing to fdo stuff (60 kb/s peak transfer speed) and WARP helped me get back to normal speed
15:49 fdobridge: <Sid> interesting
15:50 fdobridge: <Sid> inb4 it just sets 1.1.1.1 as your DNS
15:50 fdobridge: <Sid> oh, yup
15:50 fdobridge: <Sid> xD
15:50 fdobridge: <mohamexiety> it depends on where the source of the issue is though. if the throttling is from the fdo side and not somewhere in the middle then it wont help
15:51 fdobridge: <mohamexiety> it does that and other stuff, but I dont remember entirely what else it did
15:51 fdobridge: <Sid> mhm
15:51 fdobridge: <Sid> I should go back to using quad9 as my DNS too..
15:54 fdobridge: <Sid> 300KB/s...
15:54 fdobridge: <Sid> oh well
15:54 fdobridge: <Sid> guess I'll play a game in the meanwhile
15:54 fdobridge: <Sid> vampire survivors happily runs at the engine cap of 240 FPS on NVK on my laptop 1660Ti
15:55 fdobridge: <redsheep> I'm not sure I ever did test my AMD iGPU after nouveau_use_zink got added, maybe the loader hell is resolved now
15:56 fdobridge: <redsheep> I'm just always worried my testing is somehow ending up on the wrong gpu
15:56 fdobridge: <Sid> use the DRI_PRIME env var with the PCI ID method
15:57 fdobridge: <redsheep> Right, but you said yourself just a little while ago that you had things going to the wrong gpu
15:57 fdobridge: <Sid> if you're testing things inside a session, it's respected 100% of the time
15:57 fdobridge: <Sid> if you're trying to start a session with it, things are more wonky
15:57 fdobridge: <Sid> because, well
15:57 fdobridge: <Sid> it has to render on nv and present via intel on my hardware
15:58 fdobridge: <Sid> oh we're back down to 80KB/s
15:58 fdobridge: <Sid> epic
16:04 fdobridge: <redsheep> I'll probably test it again soon, but regardless of whether it's supposed to be certain that it is respected it still makes me uneasy. It was just completely reporting the wrong gpu to the applications I was testing.
16:04 fdobridge: <Sid> DRI_PRIME=1 is wonky, yes
16:05 fdobridge: <Sid> because it depends on what order your GPUs get enumerated in at boot time
16:05 fdobridge: <Sid> pci path is solid
16:13 fdobridge: <gfxstrand> While @tiredchiku is playing with her setup, I'm going to take a look at this MSAA nonsense. I saw some piglits failing yesterday which might provide a clue.
16:14 fdobridge: <gfxstrand> At this point, kwin_wayland appears to be working for me.
16:15 fdobridge: <Sid> I'm just waiting on this kernel source to download .-.
16:15 fdobridge: <redsheep> If that dead ends there's also this guide I put on getting it in renderdoc https://discord.com/channels/1033216351990456371/1034184951790305330/1233758838478606368
16:15 fdobridge: <Sid> I did see weird artifacting wrt MSAA in Dirt Rally 1 as well
16:15 fdobridge: <Sid> native, over zink
16:15 fdobridge: <Sid> entire textures flickered in and out of existence
16:16 fdobridge: <gfxstrand> What's a .cap file?
16:16 fdobridge: <redsheep> It's a preset for doing a renderdoc capture
16:17 fdobridge: <redsheep> Basically I figured out how to run heaven directly so that renderdoc can capture
16:17 fdobridge: <gfxstrand> ah
16:17 fdobridge: <redsheep> Normally the launcher breaks it
16:23 fdobridge: <redsheep> Maybe that is actually broken for me is not kwin, but the rest of the session starting
16:24 fdobridge: <redsheep> If a black screen and cursor is the expected result of kwin alone, well... That is what I get
16:26 fdobridge: <redsheep> How do i get gears to come up when I've manually started just kwin?
16:27 fdobridge: <gfxstrand> SSH in and launch it
16:30 fdobridge: <Sid> oh hey the kernel build began
17:10 fdobridge: <Sid> built and installed, I'll test after tomorrow's exam
17:11 fdobridge: <gfxstrand> Hrm... piglit's ext_framebuffer_multisample-formats always fails on the 2nd subtest
17:11 fdobridge: <Sid> feeling rather out of it right now, probably just gonna crash
17:11 fdobridge: <gfxstrand> that's okay
17:11 fdobridge: <gfxstrand> I am too
17:13 fdobridge: <Sid> here's good news though
17:13 fdobridge: <Sid> NVK renders sway without an issue
17:14 fdobridge: <Sid> even on prime render shenanigans
17:14 fdobridge: <magic_rb.> 🎉🎉🎉
17:14 fdobridge: <Sid> `WLR_RENDERER=vulkan DRI_PRIME=pci-0000_01_00_0 sway`
17:15 fdobridge: <Sid> kde is just a bit tedious to test because if I end up with an unusable session, reboot seems to be the only clean way to end it
17:17 fdobridge: <redsheep> I'm trying to test more and the really annoying flicker I was seeing ok plasma x11 is back, and happens in Kate as well as Konsole
17:17 bl4ckb0ne: Sid vnice
17:18 bl4ckb0ne: wanted to try sway with nvk for ages but im stuck on bookworm, glad to know its going fine
17:20 fdobridge: <Sid> unfortunately I think NOUVEAU_USE_ZINK is borked, because gnome shell loads nouveau gl even with it set
17:20 fdobridge: <Sid> but if I use MESA_LOADER_DRIVER_OVERRIDE=zink, kitty fails to launch in the session (which doesn't happen with NOUVEAU_USE_ZINK)
17:21 fdobridge: <Sid> or even without
17:22 fdobridge: <Sid> I'll test things properly with an external display on either wednesday or thursday
17:26 fdobridge: <Sid> turns out gnome doesn't end the session if you use the UI to log out and didn't use a display manager to start it
17:26 fdobridge: <Sid> *sigh*
17:27 fdobridge: <Sid> kde does, for the record. it ends the session and drops you back to tty
17:35 fdobridge: <redsheep> Maybe there's some other step or detail I am missing, logging into ssh and while I have a session running and launching glxgears just yields ```Error: couldn't open display (null)```
17:36 fdobridge: <gfxstrand> You also need `WAYLAND_DISPLAY=wayland-1` or maybe `wayland-0`
17:37 fdobridge: <gfxstrand> It's fine if I run without -auto. 🤦🏻‍♀️
17:45 fdobridge: <redsheep> Hmm. Seems my desktop has to load for my wifi to connect, so I can't actually ssh in when it's in the broken state. I'm not sure this is testable on my setup.
17:47 fdobridge: <Sid> log into a different tty
17:47 fdobridge: <Sid> and use nm-cli to connect to the network
17:48 fdobridge: <redsheep> If I get time later I'll just fetch an Ethernet cable
17:48 fdobridge: <Sid> I might set up a VM with passthrough tomorrow tbh
17:49 fdobridge: <Sid> just to have an NV only system I can test on
17:49 fdobridge: <Sid> s\/system/environment
17:49 fdobridge: <Sid> or might get a cheap small HDMI display meant for raspberry pis
20:21 fdobridge: <airlied> @gfxstrand btw I installed my copr and gnome-shell hit a rust assert in nil somewhere on startup, but I won't have time to dig into it until next week
20:23 fdobridge: <gfxstrand> @airlied I think I fixed those
20:24 fdobridge: <gfxstrand> @airlied Also, you should be pulling from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795 now
20:29 fdobridge: <airlied> okay I'll regen from that
20:33 fdobridge: <airlied> oh I screwed up yesterday anyways, I didn't rebuild properly
21:34 fdobridge: <gfxstrand> Do we have a bug open for the unigine flicker?
21:37 fdobridge: <airlied> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10786
22:38 fdobridge: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29147
22:39 fdobridge: <gfxstrand> That fixes Unigine MSAA
22:45 fdobridge: <zmike.> \o/
23:58 fdobridge: <gfxstrand> And... blog post is done now, too.
23:59 fdobridge: <gfxstrand> If anyone wants to get me a cool screenshot of something running in gamescope for the end of my blog post, I'd like that. It doesn't need to have a screenshot but screenshots make blog posts look cool.