00:00 fdobridge: <a​irlied> also it appears the vmm allocation issue isn't solved with gsp, so bit more digging required
00:56 fdobridge: <k​arolherbst🐧🦀> nah, we can probably read them out on the CPU no problem
00:57 fdobridge: <k​arolherbst🐧🦀> it's just a register, the temperature stuff is pretty boring and straight forward
01:51 fdobridge: <a​irlied> https://www.phoronix.com/news/Nouveau-Maintainer-Resigns since it's official now
02:01 fdobridge: <g​fxstrand> `Pass: 405234, Fail: 94, Crash: 72, Skip: 3195085, Timeout: 2, Flake: 396, Duration: 1:47:05`
02:03 fdobridge: <g​fxstrand> I really don't know what I fixed....
02:08 fdobridge: <a​irlied> pastebin the failures list 🙂
02:18 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1153515353276690502/message.txt
02:19 fdobridge: <g​fxstrand> A lot of the remaining fails require me finding headspace to think way too hard about MSAA interpolation.
02:26 airlied: whats the comp xchg crash?
02:55 fdobridge: <g​fxstrand> I just haven't hooked them up. Someone at Collabora has been supposedly poking at it. I need to ping him.
04:30 fdobridge: <b​enjaminl> I should probably rebase the many_draws fixes now that the new uapi is merged...
06:10 fdobridge: <a​irlied> @gfxstrand just looking at nak commits, was codegen saturating depth writes?
06:11 fdobridge: <g​fxstrand> Yes. I'm sure that's why you failed at implementing unrestricted depth. But also I had to add it in even though that seemed kinda wrong. More thinking needed, I think.
06:13 fdobridge: <a​irlied> that might have been a missing piece alright, maybe once nak lands I'll figure it out
06:17 fdobridge: <g​fxstrand> The NAK patch seems really wrong to me. I'm sure something is necessary but IDK what yet.
08:20 fdobridge: <a​irlied> I created a fedora copr with a linux-firmware with the gsp bits in the right places, https://copr.fedorainfracloud.org/coprs/airlied/nouveau-gsp/
08:23 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I already packaged the firmware for Arch: https://aur.archlinux.org/packages/nouveau-fw-gsp
08:24 fdobridge: <a​irlied> in the proper form for the driver to load them?
08:25 fdobridge: <a​irlied> it appears so, nice!
08:26 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> The script feels like a mess to me though
08:26 fdobridge: <m​arysaka> I don't think it's valid @asdqueerfromeu
08:26 fdobridge: <a​irlied> they will just end up in linux-firmware eventually
08:26 fdobridge: <m​arysaka> the version have the dot now
08:26 fdobridge: <a​irlied> oh yeah the dot
08:26 fdobridge: <m​arysaka> the version have the dots now (edited)
08:26 fdobridge: <a​irlied> yes you probably don't have dotted versions
08:26 airlied: TimurTabi: also the fw extractor script needs to add the dots
08:26 fdobridge: <m​arysaka> I made a package last night trying to get it working on my fedora ahah I guess I will move to yours
08:27 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Time to update the package now (this was designed for an older GSP kernel)
08:27 fdobridge: <a​irlied> I might see about working with dakr on a prebuilt kernel for Fedora testing
08:28 fdobridge: <a​irlied> I also realised my repo will conflict with some nvidia packages, so I might rethink where I place stuff
08:28 fdobridge: <a​irlied> also mine in untested as of yet, will have time tomorrow hopefully
08:28 fdobridge: <m​arysaka> Also I think it should be mentioned that ``NvGspRm=1`` is required for non Ada cards
08:29 fdobridge: <a​irlied> if I prebuild a kernel I'll turn it on by default
08:33 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Also lib32-vulkan-tools is outdated (I wanted to update it to 264 but Khronos only had 263 despite having 264 headers)
08:35 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I just updated that package (now it's time for GSP)
08:47 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> For some reason some of the patchwork patches are encoded in base64 🤔
09:20 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1153621710629781524/fdo-patchwork-123876-nobase64.patch
09:27 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Also 2 patches are definitely missing from series (`disable vbios parsing when running on RM` and `add support for booting GSP-RM`)
14:03 fdobridge: <c​onan_kudo> Can we send him a gift basket? I've always appreciated his work, even if the internet(tm) didn't...
15:55 TimurTabi: airlied: already on it. Ben gave me a heads' up.
17:41 makinbacon21: hello! got a question re: nouveau current ampere support
17:42 makinbacon21: is anything blocking jetson orin support? stuff would have to be kang'd from previous devices to add ga10b, but like re: firmware etc, are there any hard blockers?
17:45 karolherbst: makinbacon21: firmware
17:46 karolherbst: we asked nvidia and nobody was interested in providing those firmware files as mostly nobody even asks for this
17:46 makinbacon21: mmmm so i heard...very sad
17:46 makinbacon21: can it not be dumped?
17:46 makinbacon21: i know that can't be hosted but like
17:46 makinbacon21: for testing
17:46 karolherbst: then it can't be distributed
17:46 karolherbst: but the interfaces are also weird
17:47 karolherbst: if anybody wants to do the work, good, but I think it's easier to just wait until GSP is ready and use that instead
17:47 karolherbst: not quite sure what needs to be done for Jetson, but then we'd just use the identical firmware nvidia uses
17:47 makinbacon21: yea been looking at the gsp stuff...doesnt that stuff load rn? is it worth taking a shot at adding ga10b stuff?
17:48 karolherbst: Ben posted patches for this yesterday, and you could also just use Ben's branch
17:48 karolherbst: no idea how much work would be needed on top of that for ga10b
17:49 makinbacon21: yea i was planning to take a look at it but didnt know if gsp would "just work"/if tegra uses some weird different model
17:49 makinbacon21: but fwict it does not
17:50 makinbacon21: so that's cool, maybe ill fork ben's branch and give it a try
17:50 karolherbst: yeah.. it might just work, but I suspect some tegra integration stuff might be needed
17:50 makinbacon21: target fwiw: some form of rendering hw accel in android
17:50 makinbacon21: we booted to launcher with nvidia-drm + swiftshader
17:50 makinbacon21: but ofc no fw loading and cpu rendering is garbage
17:51 makinbacon21: and nvidia-drm is just a framebuffer without nvgpu etc
17:51 makinbacon21: so nouveau seems like a reasonable target
18:08 makinbacon21: so other question, is nvidia-drm + nvidia a suitable tegradrm replacement for this case?
18:08 makinbacon21: my understanding is that tegradrm was soley responsible for firing up the display controller and making a drm-compatible disp node
18:09 makinbacon21: then mesa tegra drive would like combine the nouveau render node and the tegradrm fb node
18:09 makinbacon21: and afaik, nvidia does the dc init and nvidia-drm creates a drm-compatible fb node, and it could be used the same way
18:09 fdobridge: <a​irlied> Does orin have gsp? I didn't think it did
18:13 makinbacon21: https://gitlab.incom.co/CM-Shield/proprietary_vendor_nvidia/-/tree/lineage-20/t234/r35/firmware/ga10b?ref_type=heads
18:13 makinbacon21: that's what we have for l4t
18:13 makinbacon21: from*
19:49 fdobridge: <b​utterflies> `nvgpu` is an old style driver
19:49 fdobridge: <b​utterflies> not a GSP-heavy one
19:54 fdobridge: <a​irlied> gsp isn't a driver decision as much as a hardware one
20:51 raket: ]
20:54 fdobridge: <2​46tnt> Is there any published benchmark of gsp-enabled nouveau + mesa somewhere ?
20:55 fdobridge: <a​irlied> nope, I'm sure phoronix will get on it soon
21:32 fdobridge: <e​sdrastarsis> I did a benchmark with glmark2, but it was a while ago and it's not as complete as Phoronix's