09:38 Venemo: MrCooper_: is there a way to temporarily disable direct scanout in mutter and/or gnome-shell?
09:39 Venemo: MrCooper_: it seems to be causing "blinking" (the monitor goes black for a second)
09:42 Venemo: MrCooper_: not sure if it's a mutter/gnome-shell issue or an amdgpu/dc issue
09:42 jadahl: Venemo: Alt-F2 -> `lg` -> `global.compositor.disable_unredirect()`
09:42 Venemo: thanks jadahl. do you have a clue how to debug where the problem is?
09:43 jadahl: MUTTER_DEBUG=kms,render or Alt-F2 -> `lg` -> Flags -> enable KMS/RENDER. that should show when you do direct scanout or not, as well as what's posted to KMS
09:44 Venemo: I mean, how do I know if it's an issue with the kernel driver or with the compositor?
09:45 jadahl: good question, I have no other idea than trying to disable direct scanout, and inspecting what is sent to the kernel to see if it looks correct
09:45 MrCooper: Venemo: kernel is more likely, the mutter debug logging described by jadahl should allow ruling out any mutter issue
09:45 Venemo: what should I see (and where) once I enabled the KMS and RENDER flags?
09:46 Venemo: in the journalctl?
09:47 MrCooper: generally yes, technically wherever gnome-shell's stderr goes
09:47 Venemo: okay
09:56 Venemo: jadahl: not sure if I got the right details, but here you go: https://paste.centos.org/view/raw/eb6307e1
09:57 Venemo: the 'blink' happens when I put an application to full screen
09:57 Venemo: can record a video if it's not clear what I'm saying
09:59 MrCooper: I see no errors from drmModeAtomicCommit reported, and mutter doesn't use the DRM_MODE_ATOMIC_ALLOW_MODESET flag, so any blinking should be a kernel issue
10:00 Venemo: that's what I was afraid of :(
10:01 Venemo: guess I should try older kernel versions and then bisect.... :(
10:02 jadahl: also the logs confirm there is a direct scanout
10:02 Venemo: the logs are very confusing because they sometimes say there is and sometimes there isn't, even if there is no change
10:03 Venemo: or maybe those messages are for different crtcs?
10:03 jadahl: there seems to be two crtcs, one (86) got a direct scanout commit, the other (90) got a composited buffer
10:03 jadahl: yes
10:03 Venemo: thx
10:04 Venemo: yes, that looks like that's exactly what's happening then
10:14 Venemo: jadahl, MrCooper for clarity, here is an illustration of the issue: https://drive.google.com/file/d/1NB9UYsSpoiswUZxV-IPvdU4ZDXNa62Qy/view
10:14 Venemo: if this is indeed a kernel issue, I don't understand how it could have made it through amd's CI and display testing
10:15 MrCooper: it's probably a pretty specific issue, seems to work fine on most setups
10:15 Venemo: it triggers on RDNA4 very obviously
10:16 MrCooper: from mutter's PoV, direct scanout vs compositing makes very little difference in terms of KMS API usage, the main difference is that the buffer was allocated by the client instead of by mutter itself
10:16 Venemo: I haven't seen it on any older GPUs yet, though
10:17 MrCooper: I doubt it affects all of RDNA4, certainly haven't noticed it on my 9070
10:17 Venemo: this is a 9070 XT
10:17 Venemo: should be the same, from the perspective of the display hw
10:18 MrCooper: the buffer KMS modifiers might be a factor
10:18 Venemo: huh.
10:19 Venemo: does not happen when I set the refresh rate to 60 hz
10:19 K900: Bad cable?
10:20 K900: Chair magic?
10:20 Venemo: K900: same monitors with same cable work just fine with literally every other gpu generation
10:25 Venemo: what a weird problem
10:28 Venemo: yup, it's a kernel regression. issue does not happen on 6.16.10
10:30 Venemo: I still see some random 'blinking' on 6.16.10 though, but this time it doesn't seem related to direct scanout
13:32 pq: I'm getting a GL ES 3.2 context with Mesa 25.2.4. Why would I not see EXT_shader_framebuffer_fetch_non_coherent supported?
13:32 pq: even on llvmpipe
13:38 zmike: that's strange
13:38 zmike: I see it supported
13:39 zmike: and there are no conditionals for its support in llvmpipe
13:39 pq: yeah, I'm baffled
13:40 pq: ...let me check if the extension string might be truncated
13:40 zmike: I'm just looking at glxinfo
13:46 pq: ha, my bad. Brown paper bag bad.
13:49 zmike: we've all been there
13:51 pq: it helps if I actually look for the string I want to find
14:49 pq: radeonsi polaris11 not, haswell yes, llvmpipe yes for GL_EXT_shader_framebuffer_fetch_non_coherent, does that make sense?
14:52 pq: I think docs/features.txt agrees.
14:55 pq: Good enough for me. :-)