01:37 fililip: Venemo: gotcha, should I report it then?
01:37 Venemo: fililip: sure
01:38 Venemo: for me this only happens when I use 4K at 120 Hz or more
08:14 MrCooper: fililip: no
08:14 MrCooper: not expected
08:43 MrCooper: fililip: I guess direct scanout → compositing could result in a spike (depending on how frame time is measured) if the compositor is too optimistic about how long its compositing work takes, not the other way around though
09:36 fililip: MrCooper: hm, for me it happens both ways, it's enough for the cursor to appear in kwin while in fullscreen and then the same thing when it disappears
09:37 fililip: but yes, I'm also at 4K and at 160Hz
10:03 MrCooper: fililip: that shouldn't prevent direct scanout though; how exactly do you determine there's a "frame time spike"?
10:07 fililip: MrCooper: the whole desktop stutters for a short time
10:08 fililip: including the fullscreen client
10:11 fililip: Venemo: slight tangent, but would like to confirm if it's a real issue: if you have an RDNA4 GPU, do memory clock changes also create a brief lag for you? ie can you reproduce https://gitlab.freedesktop.org/drm/amd/-/issues/4753?
10:11 fililip: since you mentioned 4K >=120Hz
12:13 zamundaaa[m]: [@fililip:matrix.org](https://matrix.to/#/@fililip:matrix.org): are you sure it's not just the app reallocating its swapchain?
12:14 zamundaaa[m]: When showing the cursor in Plasma 6.5, direct scanout will be interrupted for one frame, until the cursor item is put on the drm plane
12:15 zamundaaa[m]: So the app gets told to reallocate for compositing, and in the next frame again back to direct scanout
12:15 fililip: no, in my case it takes way too much time imo
12:15 fililip: KWIN_DRM_NO_DIRECT_SCANOUT=1 or color profile: builtin gets rid of the issue
12:16 fililip: at 1080p120 it takes less time too
12:16 fililip: but it's still there
12:16 fililip: I had the same issue on a 6600XT but it was less noticeable since it took less time there too
12:17 fililip: not a huge issue on an RDNA3 APU either
12:18 fililip: I've re-checked with a game, and it's much worse when the cursor is shown rather than hidden
12:18 fililip: so it may be the case that retriggering direct scanout back and forth just multiplies the issue if that makes sense
12:19 fililip: I mostly use such apps during a time when night light is enabled for me so I never really paid much attention to it, especially since I was using a 1080p screen for a long time
12:28 Venemo: fililip: I don't have my RDNA4 with me at the moment, please remind me in mid-January
12:36 fililip: gotcha
12:37 fililip: in the meantime I filed this report https://gitlab.freedesktop.org/drm/amd/-/issues/4804
12:45 Venemo: for me this is how it looked when I used direct scanout on a 9070 XT: https://drive.google.com/file/d/1NB9UYsSpoiswUZxV-IPvdU4ZDXNa62Qy/view?usp=drivesdk
12:45 Venemo: basically the screen goes black briefly
13:16 fililip: oof
13:16 fililip: not seeing that on my setup fortunately
13:41 MrCooper: fililip: yours sounds more like a KWin issue, certainly not kernel driver
13:42 MrCooper: FWIW, mutter doesn't disable direct scanout when the cursor becomes visible
13:45 fililip: could be, but the transition itself shouldn't take that long to begin with
13:46 MrCooper: that's between KWin / Mesa / the apps
13:47 fililip: hm, well, if that's the case then feel free to close the report
13:48 fililip: zamundaaa: how hard would it be to make the cursor pipeline not rely on the GPU for rendering?
13:49 fililip: as far as I understand this, the cursor plane is just a sprite one can draw to asynchronously
13:50 fililip: (that would also solve the timing issue with changing images too I think)
13:52 MrCooper: zamundaaa[m]: alternatively, don't send dma-buf feedback for that one frame, so the fullscreen client doesn't recreate its swapchain
13:52 zamundaaa[m]: That is a completely unrelated thing
13:53 zamundaaa[m]: fililip: I already have a MR that makes direct scanout not be interrupted when the cursor is shown
13:53 zamundaaa[m]: It was just caused by some of the overlay / underlay changes in 6.5
13:55 fililip: which commit hash is that?
13:57 zamundaaa[m]: It's in the branch work/zamundaaa/include-ds
13:58 fililip: thanks!
14:01 zamundaaa[m]: MrCooper: I have thought about making dmabuf feedback a bit lazy in general
14:02 MrCooper: yeah might make sense, though in this case it sounds accidental anyway
14:02 zamundaaa[m]: Even with that MR, if KWin moves a surface between two planes, it could still get different dmabuf feedback for one frame
17:01 Venemo: zamundaaa[m]: it looks like on kde there is a page flip timeout after a successful gpu recovery, when adaptive sync is enabled. is this a known issue? I have not seen the same on other DEs
17:12 zamundaaa[m]: Venemo: never heard of that specifically, but it wouldn't surprise me
17:12 zamundaaa[m]: It not happening on other DEs could be influenced by the fact that at least Gnome just doesn't support GPU resets, so you wouldn't necessarily hit the issue there, you'd be logged out instead
17:13 fililip: Venemo: does it happen after a display hotplug or just normally?
17:13 fililip: it might be broken after a hotplug
17:15 zamundaaa[m]: Nowadays KWin's debug logging is very effective at ensuring users don't flood our own bug tracker with pageflip timeout messages, so I don't know that much anymore about the circumstances of more recent pageflip timeouts
17:53 Venemo: zamundaaa[m]: they now flood the drm/amd bug tracker instead
17:53 Venemo: fililip: it happens all the time. there is no hotplugging, as you can see on the video
17:56 zamundaaa[m]: Venemo: I wasn't under the impression the bugs were gone, I just don't interact with them myself as much anymore
17:57 zamundaaa[m]: (outside of the one affecting my own laptop ofc)
17:57 Venemo: yeah
17:58 Venemo: well, cosmic also handles gpu recovery and it seems to not suffer from this problem, though I don't know enough details to elaborate why
18:00 zamundaaa[m]: In terms of bug reports, might just be from the difference in user numbers
18:01 Venemo: I mean I was running it on the same computer, reproduced the same hang and there was no page fault timeout
18:01 Venemo: sorry I mean there was no page flip timeout
18:04 zamundaaa[m]: Maybe cosmic comp commits sooner or closer to vblank
18:05 zamundaaa[m]: But if you can consistently reproduce the timeout, that's at least something
18:09 Venemo: dunno if it's "the" timeout that others are reproducing. just noticed while I was testing something completely different
18:53 zamundaaa[m]: There's definitely many different causes for timeouts, but timeouts triggered by GPU resets seem to be the most common on dGPUs
18:54 zamundaaa[m]: The one I have on my laptop seems to be triggered by PSR instead
18:59 Venemo: hm
18:59 Venemo: which chip is that out of curiosity?
19:00 zamundaaa[m]: It's a 7840U
19:02 Venemo: I see. that would be Phoenix
22:41 fililip: I seem to be getting a pageflip timeout when I abuse LUT changes by hitting 'suspend' on the night light applet but they recover after 5s on my 9070
22:41 fililip: regular slow night light transitions are ok though they just cause brief freezes