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