00:07 fdobridge: <g​fxstrand> I did and it didn't reclock anything
00:13 fdobridge: <k​arolherbst🐧🦀> nothing of that works automatically by the way
00:14 fdobridge: <k​arolherbst🐧🦀> there will be a `pstate` file inside debugfs you can mess around with
00:15 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> But modern DXVK needs Vulkan 1.3 (so it's important to fix that in the future)
00:15 fdobridge: <g​fxstrand> Oh...
00:15 fdobridge: <g​fxstrand> Ok, good to know.
00:15 fdobridge: <k​arolherbst🐧🦀> yeah...
00:16 fdobridge: <k​arolherbst🐧🦀> the hardware can't do it and we don't have firmware doing it for us
00:16 fdobridge: <k​arolherbst🐧🦀> and I never got to actually upstream all the firmware assembly code + whatever it needs to do it properly
00:16 fdobridge: <k​arolherbst🐧🦀> there are just painful ways
00:17 fdobridge: <k​arolherbst🐧🦀> mhh actually.. you might need more patches...
00:17 fdobridge: <k​arolherbst🐧🦀> to load our own PMU firmware to do the memory reclocking as well
00:18 fdobridge: <k​arolherbst🐧🦀> I want to fix some other nouveau issues anyway, so maybe I just do it on maxwell2 and also look in rebasing whatever is needed
00:20 fdobridge: <g​fxstrand> Kk
00:20 fdobridge: <g​fxstrand> Any chance this can happen in the next couple weeks?
00:21 fdobridge: <g​fxstrand> At least in a sketchy enough state I can do a demo with it
00:24 fdobridge: <g​fxstrand> So I'm seeing a `/sys/class/drm/card1/device/power_state` and a `/sys/class/drm/card1/device/power` folder
00:38 fdobridge: <g​fxstrand> What am I supposed to do with these files?
00:40 fdobridge: <a​irlied> it will be in /sys/kernel/debug/dri/
00:42 fdobridge: <g​fxstrand> ok, what do i do with it?
00:45 fdobridge: <g​fxstrand> Ok, seems I can cat things to it
00:48 fdobridge: <g​fxstrand> Ok, cat'ing things at it, I can get the 980m to match the SKL integrated perf. 😰
00:50 fdobridge: <k​arolherbst🐧🦀> but only the core clock changes, right?
00:50 fdobridge: <k​arolherbst🐧🦀> not the memory one
00:51 fdobridge: <k​arolherbst🐧🦀> let's see...
00:52 fdobridge: <g​fxstrand> could be? Looking at `pstate` makes it look like both are changing but IDK that I can trust that
00:52 fdobridge: <k​arolherbst🐧🦀> mhhh
00:52 fdobridge: <k​arolherbst🐧🦀> it should read it out from hardware
00:52 fdobridge: <k​arolherbst🐧🦀> but does it match the `0xf` perf state?
00:54 fdobridge: <k​arolherbst🐧🦀> @gfxstrand ohh if you do render offloading you'll probably be limited by the pcie bus speed
00:54 fdobridge: <k​arolherbst🐧🦀> not sure if that's changed...
00:54 fdobridge: <k​arolherbst🐧🦀> it's annoying that there are so many variables to this
00:56 fdobridge: <k​arolherbst🐧🦀> should check with `lspci -vv` that the link speed bumped up as well
00:57 fdobridge: <k​arolherbst🐧🦀> but could also be we read stuff out horrible wrong and do weird things...
01:04 fdobridge: <g​fxstrand> Yeah, it seems I can set 0xf and it works
01:04 fdobridge: <k​arolherbst🐧🦀> okay
01:04 fdobridge: <k​arolherbst🐧🦀> so
01:04 fdobridge: <k​arolherbst🐧🦀> the last line with AC/DC indicates the current state
01:04 fdobridge: <k​arolherbst🐧🦀> and the current clocks
01:04 fdobridge: <g​fxstrand> yup
01:05 fdobridge: <g​fxstrand> it says `core 135-1126 MHz memory 5010 MHz`
01:05 fdobridge: <k​arolherbst🐧🦀> that's not the last line tho, is it?
01:05 fdobridge: <k​arolherbst🐧🦀> that's just the selected pstate
01:07 fdobridge: <k​arolherbst🐧🦀> mind pasting the entire content? I might also misremember
01:07 fdobridge: <k​arolherbst🐧🦀> and there might be a new bug now.. mhh
01:09 fdobridge: <g​fxstrand> `lspci -vv`
01:09 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1099864614860247121/message.txt
01:09 fdobridge: <k​arolherbst🐧🦀> so at least the pcie bus shouldn't be an issue
01:09 fdobridge: <k​arolherbst🐧🦀> I still suspect the memory clocks didn't went up
01:09 fdobridge: <k​arolherbst🐧🦀> and the pstate file should tell us
01:27 fdobridge: <g​fxstrand> ```
01:27 fdobridge: <g​fxstrand> 07: core 135-405 MHz memory 648 MHz
01:27 fdobridge: <g​fxstrand> 0a: core 135-1126 MHz memory 1620 MHz
01:27 fdobridge: <g​fxstrand> 0e: core 135-1126 MHz memory 3200 MHz
01:27 fdobridge: <g​fxstrand> 0f: core 135-1126 MHz memory 5010 MHz AC DC *
01:27 fdobridge: <g​fxstrand> AC: core 0 MHz memory 0 MHz
01:27 fdobridge: <g​fxstrand> ```
01:27 fdobridge: <k​arolherbst🐧🦀> mhhh
01:28 fdobridge: <k​arolherbst🐧🦀> yeah. uhm.. no idea why it returns 0 🙂
01:28 fdobridge: <k​arolherbst🐧🦀> probably some check somewhere
01:28 fdobridge: <k​arolherbst🐧🦀> I'll see what I can figure out, but the last line shouldn't be 0, but should report the currently set clocks
01:29 fdobridge: <k​arolherbst🐧🦀> the PMU situation is a little messed up on Maxwell2 because of the secure boot situation
01:32 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Maxwell v2 and above?
01:32 fdobridge: <k​arolherbst🐧🦀> yeah
01:32 fdobridge: <k​arolherbst🐧🦀> so we load the signed firmware form nvidia to bootstrap acceleration and everything
01:32 fdobridge:<k​arolherbst🐧🦀> but
01:32 fdobridge: <g​fxstrand> I'm happy to do things that require disabling secure boot
01:33 fdobridge: <k​arolherbst🐧🦀> apparently we can still load our own PMU firmware
01:33 fdobridge: <k​arolherbst🐧🦀> nah.. not the uefi secure boot
01:33 fdobridge: <k​arolherbst🐧🦀> the uhm.. signed firmware stuff
01:33 fdobridge: <k​arolherbst🐧🦀> I had a hacky patch that kinda reset the PMU to load itself from our firmware
01:33 fdobridge: <k​arolherbst🐧🦀> the thing is..
01:33 fdobridge: <k​arolherbst🐧🦀> the PMU is also used to do this signed firmware bootstraping
01:33 fdobridge: <k​arolherbst🐧🦀> it's quite messy
01:33 fdobridge: <k​arolherbst🐧🦀> I have to see if my hacky hack even works with the current code
02:02 fdobridge: <🌺​ ¿butterflies? 🌸> I don't think that HS is mandated...
02:04 fdobridge: <k​arolherbst🐧🦀> yeah... soo..
02:04 fdobridge: <k​arolherbst🐧🦀> after we put GR into LS mode
02:04 fdobridge: <k​arolherbst🐧🦀> what I've done is, reset the PMU to go into non secure mode and load our PMU image
02:05 fdobridge: <🌺​ ¿butterflies? 🌸> perhaps you can get away with not using the GSP at all 😛
02:05 fdobridge: <k​arolherbst🐧🦀> we don't have gsp on that hardware
02:06 fdobridge: <k​arolherbst🐧🦀> but we need the HS mode to boot the context switching firmware
02:06 fdobridge: <🌺​ ¿butterflies? 🌸> meant using this instead of the GSP on newer hw too 🤔
02:10 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> GSP-less reclocking 🤤
11:41 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I'll probably wait for working reclocking (nouveau's GSP support is bad right now)
12:17 RSpliet: IIRC PMU needs to be in HS-mode on Maxwell2 to be able to access fan control registers. The reclocking itself wasn't so much the problem - although I also didn't try. You do want to do DRAM reclocking on one of those firmware cores rather than from your CPU over MMIO for timing reasons.
12:17 RSpliet: So NVIDIA's HS firmware gives fan control, open-source non-HS firmware gives reclocking. We kind of need both to actually do reclocking.
12:18 RSpliet: (but... this is digging deep into my memory)
12:20 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> @ gfxstrand Does NAK solve this limitation (I had to remove this assert for Overwatch 2 to boot into the main menu)?: https://gitlab.freedesktop.org/nouveau/mesa/-/blob/nvk/main/src/nouveau/vulkan/nvk_descriptor_set.c#L64
12:52 OftenTimeConsuming: I cannot fathom why you would call such tyrant functionality a "highly secure" mode. The only thing high is the level of digital handcuffing.
12:58 karolherbst: Well.. it does prevent hardware damages from modded (malicious or voluntarily) firmware
13:00 karolherbst: firmware can also provide userspace access to privileged mmio registers
13:00 karolherbst: which nvidia's driver depends on not getting messed up
13:01 RSpliet: a benevolent actor might consider it a tool for NVIDIA to control/deter use of their cards for crypto, or a method to protect VM from accessing each other contexts through a back-door in datacentres.
13:01 karolherbst: so you could actually exploit a system by providing custom firmware + custom userspace
13:01 RSpliet: I found these explanations a bit flimsy
13:01 karolherbst: but that attack vector is kinda pointless if you have uefi secure boot turned on
13:02 karolherbst: heck.. even nouveau will depend on the firmware being sane in this regards
13:02 karolherbst: or already does
14:40 fdobridge: <B​yLaws> Is ssbo bounds checking for robustness done in shader code?
14:41 fdobridge: <B​yLaws> Is ssbo bounds checking for robustness done in shader code, or enforced by hw somehow? (edited)
14:42 fdobridge: <k​arolherbst🐧🦀> done in shader codoe
14:42 fdobridge: <k​arolherbst🐧🦀> *code
14:42 fdobridge: <k​arolherbst🐧🦀> there is no hardware support for ssbos at all
14:42 fdobridge: <k​arolherbst🐧🦀> it's all just raw pointers
15:11 fdobridge: <g​fxstrand> Yeah, I'm torching that crap. I've not removed the assert yet but yes, we'll be doing images more properly.
15:11 fdobridge: <g​fxstrand> There's just so many of these things...
15:12 fdobridge: <g​fxstrand> It's easier to just do it right in NAK than to try to "fix" codegen and risk breaking the GL driver.
15:12 fdobridge: <k​arolherbst🐧🦀> I agree
15:12 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I wish there was a :frog_demon: emote 🐸
15:13 fdobridge: <k​arolherbst🐧🦀> speak for yourself as there is one
15:13 fdobridge: <k​arolherbst🐧🦀> no idea from where tho 😄
15:13 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> (not in this server)
15:13 fdobridge: <k​arolherbst🐧🦀> ohh right, the frog one is default.. mhhh
15:14 fdobridge: <k​arolherbst🐧🦀> but I still want fdo specific emojis 😄