08:56 MrCooper: can a KMS driver require DRM_MODE_ATOMIC_ALLOW_MODESET for a commit which does nothing other than disabling the cursor plane (set FB_ID & CRTC_ID to 0)?
09:06 pq: MrCooper, sounds weird, but if it sometimes causes a visible glitch on screen, then yes, I guess,
09:07 emersion: i don't see why not
09:08 pq: annoying to handle in userspace, I'm sure
09:56 MrCooper: turns out the problem wasn't disabling the cursor plane but that the CRTC was off both before and after the commit, and DRM_MODE_PAGE_FLIP_EVENT was used
09:57 pq: aye
10:02 emersion: hm, i recall some discussion about this being annoying
10:02 emersion: and about relaxing the kernel checks
10:49 pixelcluster: thellstrom_, tursulin: Would any of you be interested in reviewing a small TTM patchset improving dmem integration? https://patchwork.freedesktop.org/series/154528/ has been sitting for quite a while (Christian responded on the initial revision but hasn't got the time to get back to it) and I'd be happy to eventually merge it
11:02 tursulin: pixelcluster: I am happy to have a look. Just with a disclaimer that I haven't had a peek in the dmem cgroup recently so no promises I will be effective.
11:02 pixelcluster: tursulin: thanks! the dmem parts are already reviewed, just the TTM parts still need review
11:03 tursulin: ah good, that will make it easier
11:07 MrCooper: emersion: you mean the kernel would just send the event immediately for CRTCs which are and stay off?
11:23 emersion: MrCooper: it already does for the on -> off transition
11:24 MrCooper: that seems like it should actually work normally though
11:24 emersion: wdym?
11:25 MrCooper: hmm, maybe not, there may be no vblank timestamp yet when the CRTC starts scanning out
11:25 MrCooper: ugh, sorry, read it backwards (off -> on)
11:27 MrCooper: emersion: so yeah, that would make sense to me, especially since the CRTC can be off unexpectedly, e.g. due to RMFB
11:27 pq: fwiw, I am hit by amdgpu setting the pageflip timestamp to zero on off -> on transition and it kills Weston.
11:27 pq: is that not a kernel bug?
11:28 MrCooper: yeah I remember that, it is
11:28 pq: cool
11:29 MrCooper: sometimes it's better to be robust than right though :)
11:29 pq: I'll leave that to the desktop compositors. Someone has to fill in the holes in IGT. :-p
11:30 MrCooper: I wonder if AMD haven't hit that with their thing based on weston
11:31 pq: maybe they don't use cards as old as my RX 550
11:32 pq: or maybe I'm just behind in kernels, being on Debian stable, and unable to upgrade the kernel from backports because then it will corrupt my SSD.
11:34 MrCooper: I have vague recollection of hitting it with current kernels on newer HW
11:35 MrCooper: I suspect it's a bug in the common amdgpu DM code
11:36 MrCooper: melissawen: FWIW, in the "drm/drm_edid: ignore continuous frequency support for VRR" patch, kernel coding style wants curly braces around indented multi-line statements
11:56 zamundaaa[m]: pq: amdgpu also returns a zero timestamp in some other situations, IIRC if you only commit the cursor plane
11:58 pq: another hole in IGT
11:59 pq: Instead of filing bugs, I should add tests for the bugs in IGT, but... priorities
12:45 Company: zmike: while you're reviewing ycbcr lavapipe MRs, can I get you to look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39820 ?
12:46 Company:not sure what the next steps should be there after konstantin's review
12:48 mlankhorst: tzimmermann: FYI I closed drm-misc-next-fixes since we backmerged rc1 now.
12:48 tzimmermann: ok
12:49 tzimmermann: i'll send out the first PR with feature this week. fixes can again go into -misc-fixes
12:51 mlankhorst: Yeah. :-)
17:08 soreau: bluetail: Hi again, after getting too many gpu resets that crash the compositor when hovering on panel window-list button and other widgets to show tooltip in wf-panel under wayfire, I've installed the amdgpu options you recommended. I'll let you know in a few days if it seems they've helped or not. Thanks for the tips.
17:09 soreau: and FWIW, running OpenGL renderer string: AMD Ryzen 7 7800X3D 8-Core Processor (radeonsi, raphael_mendocino, LLVM 21.1.6, DRM 3.64, 6.18.9-arch1-2)
17:10 MoeIcenowy: Anyone can answer the question whether dumb buffers is linear only, and join the discussion at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38810#note_3340318 ?
17:11 MoeIcenowy: I think on display controllers with AFBC support AFBC buffers are allocated as dumb buffers, is this right?
17:14 MrCooper: "dumb" pretty much implies linear
17:14 MrCooper: the purpose of dumb BOs is for simple fallback drawing
17:15 emersion: Moe_Icenowy: i agree with Daniel here
17:16 emersion: (also, you really can trust Daniel on these matters :P )
17:19 MrCooper: yeah, some things use dumb BOs for non-generic purposes, those are pretty much hacks, which just happen to work in specific cases
17:30 MoeIcenowy: MrCooper: well I don't think I read any document about dumb buffers are only for linears -- and the AFBC-capable KMS drivers (I checked mediatek and rockchip) seem to have no way to allocate non-dumb buffers
17:31 MoeIcenowy: and with panfrost gallium driver, the scanout buffer is still created with DRM_IOCTL_MODE_CREATE_DUMB
17:32 MrCooper: that's an example of such a hack
17:34 MoeIcenowy: I can understand the `pitch` field of dumb buffers can easily be only meaningful for linear buffers, but I think if using AFBC with dumb buffers is a hack, it should be documented somewhere?
17:37 emersion: I agree it should be documented (we have ways to go regarding docs in general)
17:53 mlankhorst: What would be the correct way to unplug framebuffers? Running into this error trace: https://paste.debian.net/hidden/bcd8a337
18:01 tzimmermann: MoeIcenowy, dump buffers is only for linear
18:02 tzimmermann: for rgb pixels
18:02 tzimmermann: don't try to bend it into something else
18:02 tzimmermann: some drivers did and it's a mess
18:28 dschuermann: why do we use nir_deref_cast(load_vulkan_descriptor) for block vars instead of nir_deref_var?
19:35 zmike: is there a nir pass to delete unused functions?
19:35 zmike: closest I've found is in gl nir linker
19:36 pendingchaos: nir_remove_non_entrypoints() (only somewhat serious)
19:37 zmike: probably works since I'm inlining functions
19:37 zmike: thx
19:39 pendingchaos: if you're not, I just discovered nir_cleanup_functions(), which removes everything which isn't the entrypoint or called by the entrypoint, if options->driver_functions is true
19:39 zmike: oh huh
19:49 airlied: oh should probably add cmat_call support to that path for future proof
19:49 airlied: but then maybe I could use that path