04:45 Mangix: Venemo: found out how to install and boot a custom kernel. I can confirm 6.17 with the 6.18 patches backported sleep works
04:56 Venemo: Mangix: which patches exactly?
04:58 Mangix: I just have the stuff from 6.18 < https://gist.github.com/neheb/993809e8b6c8bb439f01fb5ea597dca1
04:59 Mangix: cloning amd-drm-next currently to see if I can get that working.
05:11 Venemo: I see
05:11 Venemo: those should be included in the next 6.17 too
05:21 Mangix: interesting. seems amd-drm-next is based on 6.16
05:22 Mangix: linux-upstream 6.17.8_00009_g4017f9e2f936-17 6.16.0_gcff16782b540-2 -0.94 MiB <-- that's just funny
05:28 Mangix: hrm interesting
05:28 Mangix: gsr error: no video encoder was specified and neither h264, hevc nor av1 are supported on your system or you are trying to capture at a resolution higher than your system supports for each codec
05:28 Mangix: maybe resolution is too high
05:28 Venemo: what are you trying to do Mangix ?
05:28 Mangix: screen record
05:29 Venemo: at what resolution?
05:29 Mangix: 2560x1440
05:29 Venemo: max is 1080p
05:29 Mangix: got it
05:30 Venemo: you can see it for yourself if you run vainfo
05:31 Mangix: VAConfigAttribMaxPictureWidth : 2048
05:31 Mangix: VAConfigAttribMaxPictureHeight : 1152
05:31 Mangix: that?
05:32 Mangix: oh wait a minute doesn't this also require firmware?
05:33 Mangix: I assume that's the reason for the zeroes https://gist.github.com/neheb/6bb1e5860f0b60b3e09adddbfd26ce1b
05:46 Venemo: Mangix: yes, and yes
05:47 Venemo: Mangix: doesn't your dmesg tell you that already?
05:47 Mangix: ah yes
05:48 Venemo: https://gitlab.com/kernel-firmware/linux-firmware/-/blob/main/amdgpu/vce_1_0_0.bin
05:55 Mangix: huh. do I just drop it in /usr/lib/firmware/amdgpu ?
05:56 Venemo: depends on your distro
05:56 Venemo: some distros compress it
05:59 Mangix: mine is full of zst files
06:00 Venemo: then you need to find out how those are made and do the same
06:00 Mangix: https://gist.github.com/neheb/dc7ebdbf43282797d99f12645c0e684a uhhh do I need to prefix with verde or omething?
07:09 Venemo: Mangix: wdym?
07:11 Venemo: https://gitlab.freedesktop.org/agd5f/linux/-/commit/fc6aa81c7319ad82a5fcf1bb6e7fad04a3f4fbf4
07:12 Venemo: there is no need to rename the file or anything
07:36 tzimmermann: i have a switcheroo patch that affects radeon and amdgpu. i'm looking for reviewers. https://lore.kernel.org/dri-devel/20251105161549.98836-1-tzimmermann@suse.de/
13:22 johnny0: hmm, anyone with a polaris card willing to confirm if reading gpu power stalls?
13:23 johnny0: e.g., for a single card system: cat /sys/class/drm/card0/device/hwmon/hwmon*/power1_input
14:19 agd5f: johnny0, only hawaii, bonaire, fiji, and tonga have to use the pm logging function to get power. Polaris uses the new smu message
14:22 johnny0: yeah, I'm looking to confirm the new message actually gets a chance to ever return nonzero
14:23 johnny0: because I can see how it might never get that chance, but I don't have hardware to confirm
14:25 tzimmermann: agd5f, thanks a lot for looking at that patch
14:28 johnny0: agd5f: can polaris even use the old logging functions as a fallback? that'd also answer the question
14:29 johnny0: well, it'd answer the question if "no"
14:30 agd5f: johnny0, I don't recall if that functionality still exists on polaris or not off hand
14:31 agd5f: there's a better replacement. the pmlog function was mostly for debugging, we just repurposed it for power
14:38 johnny0: thanks, I just want to make sure the new message is actually being used since the get_power function allows fallback to the legacy messages
14:39 johnny0: because my changes would kick that branch alive
14:43 johnny0: err... to life...
14:47 Venemo: johnny0: I have a Polaris card, just let me know what you need me to do to test it. I can then test it tomorrow or next week
14:53 johnny0: Venemo: thanks! it's pretty much just checking the power sensor and seeing if there's that 500msec lag
14:55 Venemo: how do I tell if there is a 500 msec lag?
14:56 johnny0: when you read the power via a terminal, it will take a while to return the value
14:57 agd5f: you can also just add a printk to see if you ever fall through to the smu7_get_gpu_power() to see if you ever fall through from the PPSMC_MSG_GetCurrPkgPwr case
14:58 agd5f: you can also just add a printk in the smu7_get_gpu_power() to see if you ever fall through from the PPSMC_MSG_GetCurrPkgPwr case
15:00 Venemo: johnny0: I am not sure if I can tell a 500 ms lag just from "takes a while"
15:02 johnny0: I get it, the print is probably a better option in that case
15:13 johnny0: but uh, I think you'll feel it immediately; think multiplayer game hosted on the other side of the world with no client side prediction
15:22 Venemo: alright, I'll take a look early next week at the latest
15:41 johnny0: thanks again -- if I run into something that answers the question in the meantime, I'll be sure to ping you
15:49 Venemo: johnny0: have you made any progress with the Hawaii issue by the way? do you need help with that?
15:57 johnny0: #3851? I did a bunch more testing with Hawaii/Kaveri and found more related/blocking issues
16:00 johnny0: for example, that NoDisplay/HasDisplay issue makes testing a headache on Hawaii
16:01 johnny0: and on Kaveri, setting the UMA buffer > 256M results in parallel UVD jobs getting slower over time
16:02 johnny0: and the general memory allocation behavior differences between the two makes writing up the bug reports a nightmare
16:02 soreau: gdb ain't got nuthin' on printf/k debugging ;)
16:03 soreau: ofc if it's fw or something you can't print easily, you just have to run the code in your head, like agd5f does =D
16:07 johnny0: Venemo: anyway, the best way I can put it is that there's a hydra living in the rabbit hole that is #3851
16:26 Venemo: johnny0: afaik you said you were working on a patch
16:34 johnny0: there's already a patch linked in the bug report comments and I'm not so sure the follow up patch is the right way to go
16:37 johnny0: contiguous allocations not crossing a power of two boundary seem to be drm_buddy-specific
16:38 johnny0: GTT doesn't use drm_buddy so uh, yeah
18:31 shelter: hmm... i experience that some games load much faster now. did anything change in mesa regarding this? before some games took forever to load, like AC odyssey (dxvk) and guardians of the galaxy (vkd3d-proton)
18:32 shelter: or is it something else? only thing i can think of is that i updated the nvme firmware and changed a filesystem option
18:32 shelter: it was like ac odyssey recompiled shaders each time it started... now it loads like 10 times faster...
18:37 shelter: according to kdiskmark, disk performance seems to be the same compared to before.. so i dunno
18:45 johnny0: Venemo: anyway, I'd absolutely welcome your help, I just want you to know what you'd be getting into -- the uvd init part of the issue is just the tip of the iceberg
19:03 shelter: i guess i could revert mesa and see but i have no major issues with the current build so.
19:18 agd5f: johnny0, power1_input seems instanenous on polaris. I don't have my kernel patched to see if it falls back, but I don't notice any sort of delay
19:52 johnny0: agd5f: great, thanks!
19:52 johnny0: Venemo: ^
19:52 Venemo: Awesome
21:27 Mangix: Venemo: firmware's not loading. I'm doing something wrong. I'll just wait for the arch package to update.