00:52 imirkin: StackDoubleFlow: the pscnv stuff is quite ancient
00:53 imirkin: unless you're looking for it for historical value, there's not much point
00:55 StackDoubleFlow: alright
00:55 imirkin: you're looking for PM on volta?
00:58 StackDoubleFlow: On pascal
00:58 StackDoubleFlow: my bad
00:58 imirkin: ok
00:58 imirkin: well, either way
00:58 imirkin: the PMU software must be signed by nvidia in order to have access to the "cool" stuff
00:59 imirkin: the pmu which is made available by nvidia in linux-firmware does not enable any sort of advanced PM features
00:59 imirkin: you could try to extract the pmu software that the blob uploads and go from there
00:59 imirkin: (this is not an easy task)
01:00 StackDoubleFlow: I'm not too familiar with how this works, but from what I'm gathering here, the driver sends software to the pmu on the card?
01:01 imirkin: the pmu is a CPU on the GPU which runs some little RTOS
01:01 imirkin: that RTOS is "the pmu software" that's referred to
01:02 imirkin: that RTOS makes enough calls available to the (system) CPU so that it's able to perform reclocking, fan control, etc
01:03 StackDoubleFlow: ah I see, so I would have to figure out how to send the the same rtos code, and then handle the calls it makes?
01:03 imirkin: the specific reclocking instructions are highly dependent on the RAM installed on the board
01:03 imirkin: which in turn is described in various VBIOS tables
01:03 imirkin: mmm ... more like the othe rway around
01:03 imirkin: make calls to the rtos to instruct it to do stuff
01:04 imirkin: we support this in general
01:04 imirkin: but not the specifics here
01:06 StackDoubleFlow: sure
01:06 imirkin: the main difficulty tends to be in figuring out those instructions
01:07 imirkin: in the past this has been achieved by fuzzing the vbios and seeing what instructions the blob sends
01:07 imirkin: but now everything is signed, so it's no longer an option
01:08 imirkin: maxwell2, while signed, has the same memory controller, so it all works out (except for the fact that we can't control the fan)
01:08 imirkin: but pascal has a new memory controller
01:10 imirkin: here's a quick example from e.g. gk104 https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c#n1154
01:14 StackDoubleFlow: what do you mean by signed?
01:17 imirkin: not sure how else to say it...
01:17 imirkin: it's ... signed.
01:17 imirkin: there's a signature
01:17 StackDoubleFlow: sorry I mean
01:17 imirkin: the hardware will only run the thing if there's a signature
01:17 StackDoubleFlow: How would this prevent said fuzzing
01:18 imirkin: oh, the vbios also has a signature. blob will reject it if it doesn't match.
01:18 StackDoubleFlow: Would you be making modifications to the vbios
01:18 imirkin: if you're fuzzing the blob to figure out how to interpret the vbios, then yes :)
01:20 StackDoubleFlow: oh I see what you mean now
01:22 imirkin: the vbios contains the description of the memory
01:22 imirkin: which you need in order to issue proper instructions to change memory speeds and whatnot
01:22 imirkin: but it's not like these things are documented
01:29 StackDoubleFlow: gotcha
01:32 imirkin: should make an faq about this stuff... comes up every once in a while
01:33 StackDoubleFlow: Yeah I can imagine I'm not the only one haha
05:49 Santurysim: Hello, are signatures checked on newer gpu's (pascal and later)?
05:49 imirkin: GM20x and later
05:49 imirkin: i.e. yes.
05:55 Santurysim: Thank you!
17:45 Lyude: RSpliet: you're still having the cursor issues right
19:13 Lyude: karolherbst: you managed to figure out fixes for this right? https://bugzilla.redhat.com/show_bug.cgi?id=1958506
19:13 Lyude: or are in the process of doing so?
19:14 karolherbst: Lyude: ehh.. I didn't but I have a GPU hitting it
19:15 imirkin: that's the firmware issue right?
19:15 karolherbst: yes
19:21 imirkin: that's an annoying one....
19:29 karolherbst: very
19:34 imirkin: we're doing something wrong with our ctxsw logic ... but it only ends up mattering rarely
19:34 imirkin: "yay"
20:57 RSpliet: Lyude: yes there's still very rare cursor issues
20:58 RSpliet: It's usually an early warning that the rest of the system will lock up soon
20:59 Lyude: RSpliet: oh the whole system locks up?
20:59 Lyude: RSpliet: have you actually tried reverting the changes to the cursor code that I made in nouveau recently btw?
20:59 RSpliet: Well, sometimes the context and I can restart wayland, at other times the whole GPU locks up but music keeps playing, sometimes it just dies
20:59 RSpliet: but it's a daily occurrence
20:59 RSpliet: with or without the cursor issue
21:00 Lyude: i actually wonder if something else is going on then...
21:00 RSpliet: I'm running 5.12.9-300.fc34.x86_64
21:00 Lyude: still probably worth trying to revert those patches
21:00 Lyude: RSpliet: if you want I can try to send you something to try soon this week
21:01 RSpliet: And yes, it's quite likely that something else goes wrong. I can make my GPU lock up much more reliably when playing youtube videos (using vaapi for accel)
21:02 Lyude: yeah when I was debugging the cursor issues I originally introduced on kepler I definitely don't think I managed to lock up the GPU (at least, not in ways that I wasn't already doing :)
21:05 RSpliet: This PC was more stable just after I replaced DRAM (which was broken), the CPU cooler (which was shite). But now that I'm pushing the GK107 with a 4K monitor it's more wonky again