02:53rinlovesyou[d]: nice! i'd assume vulkan video will become our bridge to do vaapi
02:54esdrastarsis[d][d]: rinlovesyou[d]: bridge = zink :happy_gears:
05:09babblebones[d]: rinlovesyou[d]: That's doable? 👀
05:09babblebones[d]: yow
05:13rinlovesyou[d]: i haven't properly looked into vulkan video
05:14rinlovesyou[d]: it can do decode and encode so i think you could totally map vaapi to it for the codecs it supports
05:15rinlovesyou[d]: either way we have options for sure
05:48airlied[d]: I've already done the decode side
05:49airlied[d]: just need zmike[d] to dig himself out of the endless pit he's dug 😛
05:50redsheep[d]: You've already done the decode side of vulkan video on nvk, or of vulkan video to vaapi via zink?
05:51airlied[d]: little bit from column a, little bit from column b
06:49airlied[d]: he decided to refactor a bunch of the mesa dri/libgl/egl/wsi loader code
06:50magic_rb[d]: Oh i remember hearing sometbing about plugguble libgbm libglvnd style, is there any progress on that?
06:52airlied[d]: this is more cleaning out the internals between glvnd and core mesa, now that we have glvnd
06:53magic_rb[d]: Random question in regard to glvnd, does it do some runtime function replacement? Because idk but doing an ifelse on every gl call seems kind of slow. Same thing with a big vtable lookup and long jump
07:13airlied[d]: afaik it has a table it fills out with all the functions, not sure how lazy it is
11:49Anon123: I have an Ampere gpu, running a kernel newer than 6.7 and have enabled nouveau.config=NvGspRm=1, where do I get temperature readings?
11:50karolherbst: you don't
11:50karolherbst: it still needs to be implemented with GSP
11:53Anon123: Didn't they release that?
11:53karolherbst: it needs code in the nouveau driver
11:53notthatclippy[d]: Can probably do it with eBPF?
11:53karolherbst: have fun :D
11:54karolherbst: but yeah.. I doubt it's gonna happen before the upgrade to a new GSP version
11:54Anon123: But the power management page says my card is supported?
11:54karolherbst: it is
11:54karolherbst: but reading out the temperature isn't power management
11:55karolherbst: ehh wait...
11:55karolherbst: maybe I have changed too much to "DONE"
11:55karolherbst: oops
11:56Anon123: Damn I contributed to open source
11:57Anon123: but really all I'm worried about is the longevity of my card, undeer nouveu shouldn't it just idle? If so then I don't need to check temps
11:57karolherbst: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/53
11:57karolherbst: Anon123: with GSP enabled the firmware takes care of all those things for us
11:58karolherbst: it's really just the part reading out the sensors and adjusting the policy which isn't supported
11:58dakr: karolherbst, not at XDC, but Plumbers and Kangrejos.
11:59Anon123: Oh so I have no reason to worry, thanks
11:59karolherbst: yeah.. in theory, I think we should still report those things via sensors/hwmon, but... that's kinda low priority atm unless somebody is willing to make those changes
12:00karolherbst: it's mostly just doing RPC calls to the firmware and figure out how the data is retrieved
12:01notthatclippy[d]: Yeah, please, don't do that :D
12:02Anon123: So even with nouveau the gpu can change pstates based on load?
12:02notthatclippy[d]: Or rather, please don't make that part of the stable uAPI. It's an okay stopgap solution, but you _will_ regret it if it sticks around. Ask me how I know.
12:03notthatclippy[d]: Yes. The big GSP firmware blob contains firmware blobs for all other microcontrollers, most notably the PMU that handles this on its own.
12:16asdqueerfromeu[d]: notthatclippy[d]: So is it possible to retrieve that hwmon information on GSP without RPC calls?
12:31notthatclippy[d]: asdqueerfromeu[d]: Weeeeeell... "not yet" is probably the simplest answer.
12:33notthatclippy[d]: The NV driver can do it as of version 545. Nouveau is on 535 so that feature is not available. But before you jump on "let's update nouveau GSP version" too much.. It's a _very_ volatile interface currently so I wouldn't rely too much on it yet.
12:33babblebones[d]: Just gonna gush a sec but when we get any pathway to vulkan video encode, oh my god wivrn will be viable :jc_woah:
12:33notthatclippy[d]: I think every major version since 545 had major changes to that interface. Turns out, that stuff is _hard_. Who'd have thunk it.
12:34notthatclippy[d]: And it's hard in all the ways that probably no one here actually cares about - virtualization, GPU partitioning, Confidential Compute, etc.
12:35notthatclippy[d]: But like I said, as a stopgap, just making the RPCs is fine, as long as it's not built into the uAPI contract in any way.
12:38notthatclippy[d]: The problem is that users tend to have multiple monitor apps all constantly spamming these requests, and GSP is single-core so it only ever services one RPC at a time. So when someone's MangoHUD requests the temperature readings at exactly the wrong time, it can stall out channel creation or whatever else actually useful work GSP needs to do. Or, it can even stall out some interrupt handling.
12:46zmike[d]: airlied[d]: https://c.tenor.com/_50huaXwY6QAAAAC/dark-knight-rises-batman.gif
12:59asdqueerfromeu[d]: notthatclippy[d]: Is that still a problem with recent NVIDIA drivers?
13:07gfxstrand[d]: phomes_[d][d]: If you're looking for something to do, https://gitlab.freedesktop.org/mesa/mesa/-/issues/11094 should be a quick enable-and-test, assuming the CTS is public now.
13:19gfxstrand[d]: notthatclippy[d]: Hopefully, nouveau can throttle and coalesce those requests a bit so we can avoid hammering the GSP too hard. For something global like frequency and thermals, that should be tractable.
13:26notthatclippy[d]: gfxstrand[d]: Throttle is a good bandaid (and also makes the uAPI contract less strict) but you can still get unlucky and make the RPC at exactly the wrong moment. And especially with 535 firmware (and doubly so on Turing) this can actually delay a vblank IRQ
13:27gfxstrand[d]: Can other GSP calls do that? Like channel creation?
13:27notthatclippy[d]: Yes.
13:28gfxstrand[d]: That seems.... less than idea.
13:29notthatclippy[d]: asdqueerfromeu[d]: I can talk about this for ages, but I doubt many folks here give a crap about the proprietary drivers. The relevant bits I guess are that to the best of our knowledge all remaining issues are due to 3rd party userspace apps doing _really_ suboptimal things and not anything inherent to GSP firmware. However, we have additional IRQ latency (particularly around vblank) improvements
13:29notthatclippy[d]: in the pipeline as well.
13:33notthatclippy[d]: gfxstrand[d]: Newer GSP versions handle it better, especially on libos3. By the time we figure out a good way for nouveau to use a new GSP, I expect this won't be much of an issue.
13:33notthatclippy[d]: Currently, nouveau is using a GSP version that was only really validated on compute/datacenter usecases and anything display-related was best effort (to put it diplomatically). These kinds of issues weren't even on the radar at the time 535 was shipped.
13:37asdqueerfromeu[d]: Hopefully newer GSP versions will have better fault logging too 🐸
13:43notthatclippy[d]: asdqueerfromeu[d]: <https://github.com/NVIDIA/open-gpu-kernel-modules/blob/535/src/nvidia/generated/g_rpc-structures.h#L294-L303> versus <https://github.com/NVIDIA/open-gpu-kernel-modules/blob/560/src/nvidia/generated/g_rpc-structures.h#L1311C20-L1325> is the bit you care about.
13:44notthatclippy[d]: Should be enough to find where the shader faulted.
13:45asdqueerfromeu[d]: notthatclippy[d]: I see 560 GSP has a more verbose structure for this part
14:16valentineburley[d]: gfxstrand[d]: It's not public yet
14:21gfxstrand[d]: 😭
14:33asdqueerfromeu[d]: Hopefully this gets assigned to Marge: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30607>
14:38valentineburley[d]: I got you
17:11illwieckz: test
17:12illwieckz[d]: test
17:18AFilius: Hi, regarding issue #377 on drm/nouveau. Is there anything i can do to push it forward? Found a workaround to prevent a crash , created 2 merge requests for it in branches linux-6.9.y and linux-6.10.y as proposed workaround(to prevent worse). but as no single feedback was given i'm not sure i should just leave it as is, or perhaps perform additional tasks/debug?
20:01phomes_[d][d]: I compared features.txt and vulkansummary output again: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30628
20:09m1syl[d]: we should just remove features.txt...
20:09m1syl[d]: its not really doing anything
20:09m1syl[d]: just replace it with some ci that runs vulkaninfo...
20:25Lyude: karolherbst: I might give a talk on some of the KMS stuff that I've been doing
20:26karolherbst: Lyude: I hope you already submitted :)
20:26Lyude: i haven't yet :S
20:26karolherbst: mhhh or is it 8pm eastern time?...
20:26karolherbst: anyway
20:26karolherbst: deadline: 12 Aug 2024, 19:59
20:26HdkR: Better go fast, the deadline is very what, a couple hours?
20:27karolherbst: ahh so it's EST?
20:27karolherbst: phew
20:27Lyude: i would imagine it's utc
20:27karolherbst: well.. that's already over then
20:27karolherbst: but it doesn't tell and the website still allows submissions
20:28karolherbst: so maybe just do it anyway
20:28HdkR: 2024-08-12T23:59:00+00:00
20:28karolherbst: sooo..
20:28karolherbst: 12 Aug 2024, 19:59 EST
20:28Lyude: i'll do a submission asap
20:28karolherbst: cool :)
20:29HdkR: No timezone indicator is rude
20:29karolherbst: very
20:34Lyude: done
20:34karolherbst: yay
20:34Lyude: Thank you for reminding me, my goal has been to get another version of my rvkms work so far onto the list before XDC so I could talk about it more
20:35karolherbst: :)
20:35karolherbst: yeah, I'm also already prepping hard
20:35karolherbst: I wonder if I can squeeze a third CTS submission into before XDC :D
20:37Lyude: it's a shame I don't think my positron will be ready by XDC :(
20:37karolherbst: oh no
20:37karolherbst: I should do the booking soon
20:37Lyude: yeah parts got delayed :P. would have been a fun little toy to bring
20:37Lyude: next year
20:40phomes_[d][d]: m1syl[d]: there is an MR for vulkaninfo in ci but it looks to have stalled https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28054
20:43phomes_[d][d]: until that is done I guess updating features.txt makes sense. But I agree that it should be automated
20:46Lyude: Is there any way with gitlab to show the differences between two branches in a merge request? Not the differences from one commit to another, but the whole thing summed up as one diff. I'm trying to figure out if there's any way to review https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/25 before I ask if they could remove all of the formatting changes, since it looks like
20:46Lyude: they tried to do that but didnt squash their commits
20:49karolherbst: Lyude: just open the changes tab? https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/25/diffs
20:50Lyude: weird, I tried that but I couldn't get it to do the whole branch at once
20:50karolherbst: ehh yeah.. I think there is a button hidden for that
20:50karolherbst: "show latest version" 🙃
20:50airlied[d]: I think changes should work if you haven't clicked on commits previously
20:50Lyude: very clearly labeled
20:50karolherbst: best name
20:51karolherbst: yeah.. if you didn't look at one commit, it should also jsut work, but yeah..
20:51karolherbst: bad label
20:51karolherbst: anyway..
20:51karolherbst: I've tried to do some CI stuff there, but we probably need a better plan for all that kernel CI stuff
20:51karolherbst: and I think it's probably better to centralize all of that into the drm-misc repo anyway
20:52karolherbst: it's not really sustainable to merge into drm/nouveau and then figure out how to merge it into drm-misc and...
21:05Lyude: yeah
21:39airlied[d]: skeggsb9778[d]: btw tu117 seems not to initialise with GSP right now gets 0x31 in the mbox