07:33 mripard: lumag: I have no idea :)
07:34 mripard: lumag: but if you figure it out, make sure to document it
07:35 mripard: given that it's used in i915's suspend path, I wonder if it's not related to the drm_mode_config_reset discussion we had, where i915 expects the private_objs to not be reset
07:35 mripard: iirc because of DP state handling
07:37 mripard: vsyrjala: ^ ?
07:48 mripard: lumag: reviews are done too
08:13 jani: mripard: lumag: I'm currently looking at unifying i915 and xe display handling wrt probe/remove/suspend/resume. If you figure any of this shit out, let me know too. ;D
09:00 sima: bbrezillon, btw for this one it's good to ask drm-misc maintainers to do the backmerge so the mess doesn't spread too far
09:00 sima: ideally before you land the patch
09:00 sima: https://lore.kernel.org/dri-devel/20260518165225.145175b1@fedora/ I mean
09:01 bbrezillon: backmerge of drm-misc-fixes into drm-misc-next?
09:02 bbrezillon: I was planning on pinging mripard or mlankhorst once the next -rc is out to do the -rc -> drm-misc-fixes backmerge
09:03 bbrezillon: didn't know you were okay with -misc-fixes -> -misc-next backmerges though
09:08 sima: bbrezillon, we have to do these as part of the committer model a few times per release anyway
09:08 sima: since we cannot rebase -next
09:08 sima: and it stays open during the merge window
09:09 sima: bbrezillon, essentially we do backmerges instead of topic branches with the committer model
09:10 emersion: could anyone review this small libdrm patch? https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/463
10:00 cbmuser: Hi, I'm not sure whether this is the right place to ask Mesa questions, but are there any download locations for mesa-amber tarballs or is amber maintained in git only?
10:01 bbrezillon: sima: okay, I'll ask for a backmerge next time then
10:01 sima: aye
10:02 bbrezillon: actually, it's not too late to do that if mlankhorst or mripard want to have a look
10:02 bbrezillon: or we can just wait until the next -rc lands, dunno
10:06 airlied: agd5f, hwentlan__ : /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3800:6: error: stack frame size (2128) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
10:06 airlied: 3800 | void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
10:06 airlied: | ^
10:06 airlied: 1 error generated.
10:06 airlied: make[7]: *** [/home/airlied/devel/kernel/dim/src/scripts/Makefile.build:289: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.o] Error 1
10:06 airlied: CC [M] drivers/gpu/drm/nouveau/nvkm/engine/disp/gm107.o
10:06 airlied: /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:3892:6: error: stack frame size (2136) exceeds limit (2048) in 'dml314_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
10:06 airlied: 3892 | void dml314_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
10:06 airlied: | ^
10:06 airlied: 1 error generated.
10:06 airlied: make[7]: *** [/home/airlied/devel/kernel/dim/src/scripts/Makefile.build:289: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.o] Error 1
10:06 airlied: make[6]: *** [/home/airlied/devel/kernel/dim/src/scripts/Makefile.build:548: drivers/gpu/drm/amd/amdgpu] Error 2
10:06 sima: mripard, I did an initial read through of the new sro stuff, and I think it looks really good
10:07 sima: mripard, I have a few bikesheds and suggestions, but all minor thus far. all the big worries are addressed
10:07 sima: mripard, so I'm leaning towards that we should land this sooner, maybe off-by-default for now, and gain experience
10:22 mripard: sima: oh, awesome
10:22 mripard: thanks a lot :)
10:23 lumag: mripard: thanks a lot!
11:42 mripard: sima: so I didn't screw up the locking too much either then ? :)
11:45 sima: mripard, aside from the big explainer why we can only readout/compare in the blocking path I don't think there's much locking to ponder
11:46 sima: but maybe I'm wrong
12:50 mripard: sima: ok, great then :)
13:07 emersion: tomba: do you have interest in reviewing the libdrm patch which adds your new formats?
13:13 DragoonAethis: cbmuser: see https://archive.mesa3d.org/older-versions/21.x/ for latest Amber 21.3.9
13:15 sima: mripard, I actually like it more the more I read around :-)
14:05 MoeIcenowy: mripard: could you check my commit right request at https://gitlab.freedesktop.org/drm/misc/kernel/-/work_items/88 ?
14:05 MoeIcenowy: BTW the auto assigning / labelling clauses in the template seems to be not working
14:05 MoeIcenowy: and got auto removed when the issue is created
14:37 hakzsam: jenatali: it seems the d3d12 drirc entry for blender is dead? or I'm missing something?
14:39 CounterPillow: vsyrjala: ping
15:24 f_: hi, has anyone seen weird behavior when trying to launch e.g. sway, where it'll try to use zink on a device supposed to use lima (and fail)?
15:25 f_: (would like to debug it, just checking to see if it's not just me)
15:26 f_: it started happening since 26.1.0, 26.0.5 does not have the issue
15:31 soreau: f_: what does `sway -d` have to say?
15:31 soreau: maybe lima fails and it falls back to zink or something
15:32 f_: no it goes straight to zink
15:33 f_: https://paste.debian.net/hidden/50a954da
15:34 f_: even eglinfo complains with that same zink error
15:35 f_: oh I think I might have an idea what's going on
15:37 jenatali: hakzsam: No, it's not dead. For Qualcomm SQ3 chips (Adreno 690) we never got updated D3D drivers that support all of the necessary features to actually flip on GL4.3
15:37 hakzsam: I see
15:42 f_: (and fwiw, this is a Mali 400 gpu, so no way it's running zink :P)
15:44 soreau: f_: is the driver available at all? does it help if you set MESA_LOADER_DRIVER_OVERRIDE?
15:45 f_: I would be surprised if it isn't available
15:45 Ermine: f_: is lima even compiled?
15:45 f_: lima is compiled
15:45 f_: it actually shows up in eglinfo, moment
15:48 f_: https://bpa.st/RGH67C33G2QK4CEPUKLUXRKANU
15:48 Ermine: is this output with MESA_LOADER_DRIVER_OVERRIDE?
15:49 f_: no
15:50 Ermine:gotta study egl
15:53 f_: that envvar still doesn't bring up sway though
15:54 soreau: f_: do you have a lima_dri.so ?
15:54 Ermine: those 'eglInitizlize failed' lines seem suspicious. But it might be because there are no display servers running?
15:55 Ermine: what do sway logs say with the envvar?
15:59 f_: soreau: it is there
15:59 soreau: f_: I would check the dates per `ls -l` for the dri files, and probably `strace` an egl process to see if it's trying the driver at all
15:59 f_: Ermine: exactly the same just without the zink error
15:59 f_: (same as the sway log above I mean)
16:00 f_: soreau: apk doesn't leave old package libraries laying around
16:00 f_: the date is correct (today)
16:00 f_: lrwxrwxrwx 1 root root 14 May 21 15:20 dri/lima_dri.so -> libdril_dri.so
16:01 f_: however it symlinks to libdril_dri.so, which has date from yesterday
16:02 f_: ...which happens to be the date when the package was built
16:03 f_: (this is 26.1.1 uploaded to alpine yesterday)
16:03 Ermine: this is not a dril! i repeat, this is not a dril!
16:04 f_: dunno, last known working version was also setup like this
16:05 Ermine: > Using EGL device /dev/dri/card0 --- I may be completely wrong, but is it supposed to use card0 as EGL device rather than card1?
16:10 MoeIcenowy: if your *_dri.so is symlinked to libdril_dri.so, then it will matter for nothing EGL-realated
16:11 MoeIcenowy: because this means the Mesa has already switched to link libgallium directly to libEGL_xxx
16:14 Ermine: f_: try adding EGL_LOG_LEVEL=debug variable
16:15 f_: https://bpa.st/YLJA
16:16 f_: and, yeah, that's an exynos4 soc
16:18 Ermine: > device is not located on the PCI bus --- /o\
16:18 f_: https://bpa.st/MBIWJFRCOI6YJD7JXNEPKHCNA4
16:19 f_: Ermine: well yeah
16:21 Ermine: > using driver lima for 3 --- so eglinfo uses the right driver?
16:22 f_: my guess is there's some "exynos" device where it tries to use zink, and sway tries that device
16:22 Ermine: the first paste is from sway ?
16:23 f_: no
16:23 f_: that's eglinfo
16:27 Ermine: okay, now try to run sway with WLR_RENDER_DRM_DEVICE=/dev/card1
16:28 Ermine: oops, WLR_RENDER_DRM_DEVICE=/dev/dri/card1
16:29 f_: "Ignoring '/dev/dri/card1': not a KMS device"
16:34 Ermine: ok, i'm out of ideas. sorry for not being helpful
16:36 soreau: f_: Do you have mesa-dri-gallium installed?
16:37 soreau: have you checked kernel logs for anything suspicious?
16:43 f_: soreau: yes, I have the driver installed
16:44 f_: and, oh, [ 1696.144515] exynos-drm exynos-drm: [drm:exynos_drm_gem_create] *ERROR* invalid GEM buffer size: 0
16:44 f_: that's new, but I haven't touched the kernel at all...
16:46 f_:looks
16:59 f_: and this is the eglinfo on working mesa https://bpa.st/OJWFWCWOOAZPXTFKFWZZVHS3TE, I suspect it might be one of these https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38810/commits but that's just a hunch
17:08 MoeIcenowy: f_: oh exynos driver has render node, this could be a little problematic
17:08 MoeIcenowy: this might be related to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38810/diffs?commit_id=adf18abb4097805c2896e350e06e3a5cad6ec68e
17:09 MoeIcenowy: although I think the Wayland compositor isn't behaving good here -- it exposes a render node not for 3D rendering
17:09 MoeIcenowy: (but it's possible that the Wayland compositor just gets the render node from Mesa EGL
17:10 f_: "exynos driver has render node, this could be a little problematic" yeah from what I can tell, most lima-supported devices have a setup like this
17:10 f_: downstream I saw a few more people on slightly different devices with the same issue
17:10 MoeIcenowy: f_: I mean the KMS device has a render node
17:10 MoeIcenowy: which isn't very common
17:10 MoeIcenowy: sunxi/rockchip/mediatek all doesn't have it
17:11 f_: ah
17:12 Ermine: so... you can try pointing WLR_RENDER_DRM_DEVICE at other nodes?
17:13 emersion: is there a way to detect whether a render node can do 3D?
17:13 MoeIcenowy: maybe it should point to render nodes instead of primary nodes?
17:13 MoeIcenowy: emersion: I think no
17:13 MoeIcenowy: maybe the only way is just to use it to initiate Mesa
17:14 emersion: right, but then if we get a failure we can't figure out the reason
17:14 f_: to be clear, I said sway because that's what I daily drive
17:14 f_: but other wayland compositors are affected, I heard
17:15 f_: I've heard phosh for example has the same issue (though it also uses wlroots, like sway, so probably not a good example...)
17:15 MoeIcenowy: yes weston seems to be affected too
17:16 MoeIcenowy: although I wonder whether initiating kmsro with a render node is a proper operation
17:17 MoeIcenowy: oh the affected weston could be only a fork
17:17 MoeIcenowy: weston queries the render devicewith `EGL_DRM_RENDER_NODE_FILE_EXT
17:18 f_: I can try weston if that helps
17:18 MoeIcenowy: but wlroots just exposes the display device
17:18 MoeIcenowy: and assume its render node is the node used for real rendering
17:19 MoeIcenowy: which isn't true for wlroots on exynos
17:21 MoeIcenowy: well it looks like either the list of zink-capable drivers or the list of kms drivers relying on kmsro but have render nodes need to be hardcoded now...
17:25 cbmuser: DragoonAethis: OK, thanks. I was confused about the naming.
17:36 MoeIcenowy: f_: I created https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41737 , although I don't whether it's good to restore the old behavior
17:36 MoeIcenowy: I don't know whether it's right although it's relied
17:40 f_: MoeIcenowy: I've been trying to compile mesa with the offending commit reverted, it's just a bit slow
17:41 f_: so it'll take a bit for me to report back
17:44 MoeIcenowy: emersion: I think of using a codepath that will fallback to llvmpipe, and then if the falling back happens, Mesa is at least properly installed
17:45 MoeIcenowy: of course this cannot prevent the situation that proprietary drivers are messed up, or the Mesa build configuration is messed up
17:47 f_: MoeIcenowy: Why fallback to llvmpipe?
17:47 f_: or maybe I misunderstood
17:47 MoeIcenowy: emersion: I am answering the question "is there a way to detect whether a render node can do 3D?"
17:48 MoeIcenowy: f_: ^
17:48 MoeIcenowy: mentioned the wrong person
17:49 f_: ah ok
17:49 MoeIcenowy: although I think trying to detect "lack of driver" is always a nonsense -- it's an unsolvable problem
17:52 MoeIcenowy: assuming some driver exists when it's not found is similar to assuming invisible pink unicorns exists
17:53 MoeIcenowy: emersion doesn't want to hardcode kernel driver names, which makes the problem more difficult
17:53 MoeIcenowy: (well I don't like hardcoding names too...
17:55 MoeIcenowy: (although in the kmsro vs zink case I cannot think of a better idea than hardcoding driver names
18:09 emersion: MoeIcenowy: unfortunately llvmpipe could mean that the user forgot to install the driver for their hw
18:12 HdkR: Vulkan at least you can filter on device type and ignore anything that is "OTHER" or "CPU" class.
18:13 HdkR: and maybe side-eye whatever a virtual_gpu means :P
18:20 emersion: i've added EGL_device_type for this purpose
18:21 HdkR: Next stop, GLX_device_type
18:21 emersion: who uses GLX still?
18:21 HdkR: Well I certainly don't use wayland :D
18:21 emersion: EGL works on X11
18:22 HdkR: Indeed
18:22 soreau: emersion: there's still sdl2 x11 videodriver though not sure if it favors egl or not
18:22 HdkR: Not super common, but it does happen, the elusive x11+egl combination
18:24 zamundaaa[m]: emersion: why does the "user hasn't installed the driver" case matter?
18:24 emersion: because users report "my desktop is super slow" issues
18:24 emersion: i prefer failing in that case
18:24 emersion: (and making lvvmpipe opt-in)
18:25 emersion: llvmpipe*
18:25 HdkR: soreau: Looks like it prefers GLX unless you're explcitly asking for GLES, or using the hint `SDL_HINT_VIDEO_FORCE_EGL`
18:25 emersion: (to be clear, when they report issues that's the happy path - otherwise they just daily-drive llvmpipe)
18:26 soreau: HdkR: my complaint is that hl2 pointer constraint only works with x11, not wayland videodriver, at least here
18:27 zamundaaa[m]: emersion: but afaiu in this case, there would be a render node with hardware acceleration as well?
18:27 HdkR: soreau: Cursor constraints missing would definitely be annoying.
18:27 soreau: to say the least :P
18:27 emersion: zamundaaa[m]: i'm not sure i'm following
18:32 zamundaaa[m]: emersion: afaiu, the problem here is that there's a KMS node and two render nodes, and the render node of the KMS device doesn't do 3D accel
18:32 emersion: ah, sorry, it seems we were talking about different things then
18:34 emersion: there is a parallel discussion about what to do when wlroots detects a render node but couldn't initialize GL
18:35 zamundaaa[m]: emersion: ah, that makes sense. Yeah, for wlroots having software rendering be an explicit fallback compositors can yell at the user for is probably best
18:36 emersion: wlroots uses "render node exists" as a hint that there is a GPU and that software rendering is likely the wrong thing to do