01:11 johnny0: fililip: is your stutter issue only observed when the 96Mhz state is involved?
01:11 fililip: at 2160p, 160Hz it is never involved, the lowest state I can set is 456MHz
01:12 fililip: it always happens no matter the state the GPU switches to
01:12 fililip: i.e. 456MHz → 772MHz does the same thing, as does 1124MHz → 1258MHz or vice versa
01:13 johnny0: interesting, thanks
01:14 fililip: agd5f said this is due to the display code / firmware performing some kind vblank alteration that causes the stutter but allows the memory reclock, if I disable FAMS it doesn'
01:14 fililip: doesn't reclock at all*
01:14 fililip: and always remains at the highest state
01:19 johnny0: have you tried a custom modeline / edid override with a bunch of extra blanking time?
01:20 johnny0: like for the case when mclk is stuck high on a much lower resolution/refresh?
01:21 fililip: I did consider it as part of a temporary solution, and think it might play a role, but I don't know what I should try to do here + RDNA3 never had this issue and reclocks just fine without any stuttering even on a 2160p 240Hz display, so I hope that this is fixable on RDNA4
01:21 johnny0: right on
01:22 fililip: and my previous 6600 XT was always stuck at 1000MHz, as I was always running >60Hz primary displays, but it consumed "only" 20W when idle, so I never paid too much attention to that
01:23 fililip: if I set a higher state now, I get around 40W with basic drawing tasks, so that's becoming an issue
01:24 johnny0: i know what you mean w.r.t. the 6600XT, but that card can idle at 3W with a tweaked edid
01:24 johnny0: which is pretty nuts
01:25 fililip: my current 9070 can do 2-3W even at 456MHz but that's due to gfxoff or something similar, but that only works if the CUs do absolutely nothing
01:26 johnny0: oh... have you tried disabling gfxoff?
01:26 fililip: no, that wouldn't help, it would likely make things worse while idle
01:27 fililip: if I keep a simple program that draws a tiny quad, the card consumes at least 23W for 456MHz but when nothing happens on the whole desktop, I get the 2-3W draw
01:27 johnny0: I don't mean about power draw
01:27 johnny0: I mean for your stuttering issue
01:28 fililip: there is no stutter when transitioning from 2-3W to 23W, there is only stutter when the memory needs a reclock, and that can stutter even if things are already being rendered
01:29 johnny0: the reason I ask is I remember seeing something like an msleep(1) call when turning off gfxoff
01:30 fililip: where was that?
01:30 johnny0: which can sleep for *much* longer than 1 msec, and that'd definitely be noticable if you are running at 180Hz
01:31 johnny0: SMU code, I was looking to see what sensors besides CIK/VI power sleep while holding a lock
01:32 fililip: was it common SMU code or per-ASIC code?
01:33 johnny0: not sure, I would have searched through both
01:36 johnny0: yeah sorry, no function names saved in my notes, just gfxoff
01:36 johnny0: which may mean that multiple asic-specific files have the same call
01:37 fililip: one thing to note is if I just have a 1080p 165Hz screen it doesn't stutter on reclocking
01:37 fililip: and 165Hz is a bit higher than 160Hz
01:41 fililip: with 2160p even 120Hz is enough to make the stuttering visible
02:50 johnny0: fililip: sorry, the gfxoff sleep i saw is in smu_v12_0_gfx_off_control(), later versions don't have it
04:06 Mangix: Wonder if there's any point in backporting amdgpu DC fixes from 6.18 to 6.12
13:55 Venemo: Mangix: sure, why not
15:31 superkuh: Terrible oftc standards requiring users to leave channels in order to change their nick. It makes this network such a hassle. No other network in the 30 I'm on does this.
16:53 Remco: superkuh: That's usually because you're in a channel where you're banned/muted/etc.
16:55 superkuh: It's when I get disconnected, reconnect as superkuh_, then have to individually part a bunch of oftc channels so I can change to superkuh and nickserv identify.
16:55 superkuh: Although given what I've seen in #radeon maybe there's justification for it. re: that troll.
16:56 Remco: The identify command here has an optional nick. So you can identify as your other nick, then change to your normal one
16:56 Remco: But then I think it auto-changes your nick. It's been a while
16:57 MrCooper: or just identify with NickServ, as I just did
16:59 fililip: Venemo: apparently someone has already root caused the compute hang, it's apparently this commit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=079ae5118e1f0dcf5b1ab68ffdb5760b06ed79a2
16:59 fililip: I'll keep testing with that reverted, maybe it fixes the issue completely
18:18 Venemo: fililip: do you have a link to a github or ml conversation?
18:52 fililip: I first saw this issue: https://gitlab.freedesktop.org/drm/amd/-/issues/4861, then someone linked this one: https://gitlab.freedesktop.org/drm/amd/-/issues/4765, and from there I found the offending commit
18:53 fililip: for now I'm not seeing any comp timeouts but time will tell
20:37 Venemo: interesting
20:38 Venemo: thanks fililip
20:50 Venemo: it's surprising that a kfd commit can mess up radv
21:04 fililip: I think I saw this a while ago and could not believe this was related since I don't even use kfd, well, it seems to be
21:05 fililip: that's why I didn't think of this at all, the original issue talked about ollama too, which I thought was only able to use kfd