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