12:53 karolherbst[d]: I'm starting to reach the point where register usage is becoming a problem 🥲
13:46 karolherbst[d]: anybody looked into setting the perf mode through GSP? I might add it through debugfs or something to get more stable benchmark numbers, becuse I do notice that heat does affect benchmarks...
14:47 marysaka[d]: karolherbst[d]: you should probably set the stable thing from the perf headers (I think it's one of the 2080 ones)
14:47 marysaka[d]: like there are stable and boost mode + MMA boost there, nsight seems to set those when setting itself up
14:49 karolherbst[d]: yeah.. something like that
14:49 karolherbst[d]: shouldn't be too hard, just need an interface to toggle it and I'd rather have it a debugfs thing than a module parameter or something
14:49 karolherbst[d]: dunno... tho
14:49 karolherbst[d]: do we have any higher level APIs that allow to do that sort of things?
14:50 marysaka[d]: `NV2080_CTRL_CMD_PERF_RATED_TDP_SET_CONTROL` I think it's the one you want
14:51 marysaka[d]: karolherbst[d]: I mean debug fs with some module parameters might do the job?
14:51 karolherbst[d]: why a module parameter?
14:51 karolherbst[d]: could just have a toggle in debugfs
14:52 karolherbst[d]: mhhh
14:52 karolherbst[d]: that interface seems to be more complicated...
14:58 marysaka[d]: yeah it's a bit annoying to do that nicely with debugfs
15:17 notthatclippy[d]: fwctl seems like a good match for this stuff
19:11 airlied[d]: I think we just use sysfs or debugfs on other gpus
19:15 karolherbst[d]: sysfs is de-facto UAPI, so I'd rather not if we don't have to
19:15 karolherbst[d]:though
19:15 karolherbst[d]: I see merits in having a standardized UAPI for benchmarking purposes...
20:03 airlied[d]: Well you don't have to expose the sysfs file if you can't support it
20:04 airlied[d]: You can design uapi so that not existing is okay
20:35 notthatclippy[d]: Direct fwctl to GSP to allow making any 0000/0080/2080 RM control using the per-app triplet nouveau already creates. This way you can mess with stuff and build your userspace much faster without needing bespoke kernel patches for each thing you discover. If a particular RPC ends up being worthwhile to productize, _then_ you make it a uAPI as ioctl or sysfs
20:38 airlied[d]: yeah no 🙂
20:39 airlied[d]: though a debugfs for that might not be insane, but definitely not something that is exposed by default
20:42 marysaka[d]: that would be nice to have around behind a flag yeah
20:55 airlied[d]: also taking a look at the list of ctrl's nvidia defines as rpc calls might be useful to know which ones are used 😛
20:58 airlied[d]: let's just always set NV2080_CTRL_PERF_BOOST_FLAGS_CUDA_YES, NV2080_CTRL_PERF_BOOST_FLAGS_CUDA_PRIORITY_HIGH 😛
20:58 airlied[d]: though we could probably definitely toggle NV2080_CTRL_PERF_POWERSTATE_PARAMS between ac/battery
21:04 marysaka[d]: hmm isn't the whole ac/battery switch supposed to be handled via ACPI calls kinda?
21:05 marysaka[d]: hmm but it also depends if you have dynamic boost 2.x or not isn't it...
21:10 notthatclippy[d]: ac/battery is likely broken in your gsp version btw.
21:11 airlied[d]: ACPI tells the driver, but I don't think ACPI can talk to GSP
21:11 notthatclippy[d]: But the effect of the setting is so minor that it took us years to notice and no one ever filed a bug about it
21:14 notthatclippy[d]: airlied[d]: I do think you'd be doing nvk devs a huge favor by exposing this somehow. Unstable and behind an optin admin only toggle like a module param. The exact API doesn't matter but the ability to make direct gsp calls from userspace can help debug stuff a lot
21:16 airlied[d]: it just invites horrible to debug problems, esp for GSP calls that need correct object hierarchy
21:17 airlied[d]: but as a debugfs kernel tainting it might be fine
21:17 marysaka[d]: I have been typing on and off a testing backend on NVK NVKMD side for openrm, I think I will try to focus soonish but idea was to test perf diff with nouveau and prototype with some stuffs that way
21:17 marysaka[d]: airlied[d]: would also need to expose channel object handles to be able to poke at certain stuffs yeah 😅
21:17 airlied[d]: would be good to have some basic rules about what NVIDIA prop does in what cases
21:18 airlied[d]: like what the Vulkan driver hits and why
21:18 mhenning[d]: marysaka[d]: I assume you've seen the existing efforts for that?
21:19 marysaka[d]: mhenning[d]: yes I initially tried to extends the existing patches but I found myself hitting too many issues with it and ended up retyping everything
21:20 mhenning[d]: Sure, just wanted to make sure you were aware
21:20 marysaka[d]: I only am missing channel init/submissions and timeline semaphore to start running things
21:21 marysaka[d]: and then will have to type pte_kind mapping, sparse support and should be mostly okay hopefully
22:03 x512[m]: marysaka[d]: You created another NVRM NVK backend?
22:35 phomes_[d]: new MRs to run game/perf tests on today. Nice
22:53 mhenning[d]: You might not see many changes - both the 2d engine and constant color stuff is a little niche
23:00 phomes_[d]: yeah but it will be a nice change from debugging multi queue stuff 🙂
23:02 mhenning[d]: fair 🙂