08:32 mlankhorst: tzimmermann, mripard: Should we revert [PATCH] drm/syncobj: Fix handle <-> fd ioctls with dirty stack before next pull?
08:36 tursulin: if you do revert that I was a few minutes late with an important fix, now in drm-misc-fixes.
08:54 mripard: mlankhorst: should we?
08:58 mlankhorst: A problem was created when 'struct drm_syncobj_handle' was updated to the new definition from the originally mentioned commit, and then the newly compiled code did not properly initialise the new field and left stack garbage on it. The newly compiled code started failing and the original commit was blamed as causing it, as it was working before the struct update.
09:05 mripard: mlankhorst: I'm confused, so if we revert, are we still left with a problem or not?
09:15 mlankhorst: mripard: basically old definition: struct { ...; }; worked. new definition: struct { ...; u64 point; } failed when recompiling because code never used memset, or set the new field to 0, to me it seems like a user bug, not a kernel bug. :)
09:15 mlankhorst: specifically when recompiling, because the struct size is passed to the ioctl as argument
09:24 dolphin: airlied, sima: drm-intel-fixes PR sent
09:40 dolphin: airlied, sima: some of the CI results for drm-intel-fixes are still in black hole, but the BAT was looking good
10:28 reactormonk: cloning the mesa git repo fails here: https://gist.github.com/reactormonk/c977c4e3738154cd2caa2387e9673c05
11:06 daniels: Company: for EGL, you want to use EGL_ANDROID_native_fence_sync to export the fence out to a dmabuf and then poll on that
11:08 Company: I had feared that that's the solution
11:08 Company: because then I have to do custom code for each GL backend we have in GTK
11:08 Company: which technically still includes GLX even
11:09 Company: I had hoped there's some generic mechanism I can use as a fallback mechanism that always works
11:10 Company: and then use stuff like EGL_ANDROID_native_fence_sync as optimization
11:20 daniels: I'm afraid not
11:22 Company: I guess I can still do a fallback that just busy-loops, ie wakes up every 10us or 100us or so and checks if the sync has triggered yet
11:33 fluffyfreak: hi, I'm trying to build Mesa on a Raspberry Pi 5 but get an error in "meson setup build/"
11:33 fluffyfreak: "llvm-config: error: libLLVM-20git.so is missing"
11:33 fluffyfreak: "llvm-config --version
11:33 fluffyfreak: " returns "20.0.0git
11:33 fluffyfreak: "
11:34 fluffyfreak: has anyone else encountered this?
11:38 MrCooper: looks like that LLVM installation is broken
11:40 ukleinek: fluffyfreak: it's probably more relevant which Distribution you're using than the hardware platform.
11:40 MrCooper: hmm, or maybe meson's LLVM support can't handle the "git" version suffix?
11:43 fluffyfreak: Raspberry Pi OS Trixie
11:43 fluffyfreak: I've tried reinstalling/checking/etc llvm
11:44 fluffyfreak: This was building an older version of mesa, 25.something, from git 4 months ago so I'm wondering if the version requirement has been bumped
11:45 fluffyfreak: this might well be an issue with the RPi OS but since I've found it whilst building Mesa I wanted to check here first
11:45 MrCooper: offhand doesn't look related to any version requirement, something looks for a libLLVM-20git.so file and can't find it
11:46 MrCooper: maybe you need to install the -dev package which has that file
11:47 ukleinek: fluffyfreak: `llvm-config --libs` seems to emit LLVM-20git for you. If libLLVM-20git doesn't exist that's a bug in your installed llvm
11:48 ukleinek: s/LLVM-20git/-l&/
11:49 fluffyfreak: ukleinek, thanks, it does appear to be missing!
11:49 MrCooper: maybe try "apt build-dep mesa"
11:51 fluffyfreak: MrCooper, done that, it was up to date
11:52 fluffyfreak: a `sudo apt remove llvm llvm-dev` followed by an install and the file is still missing
11:53 ukleinek: on Debian llvm-config is provided by the llvm package which depends on llvm-19 on Trixie which in turn depends (transitively) on libllvm19
11:53 ukleinek: so either fluffyfreak or the PiFoundation messed with something that results in llvm-config emitting 20.0.0git
11:55 fluffyfreak: this is a Pi that was upgraded from Bookworm some time ago, which might not be the best idea
11:56 fluffyfreak: but it was working on mesa 25, rebasing to the latest mesa 26 seems bust but it might just be for me
11:59 fluffyfreak: I wonder if I should grab the 20.0.0 tag of LLVM and build/install it locally to work around this on my oddball Pi
12:00 Company: fluffyfreak: just fyi, mesa versions are number year.release, not major.minor
12:00 fluffyfreak: ah, thanks
12:00 Company: and their done once a quarter usually, so you get <year>.0/1/2/3
12:01 fluffyfreak: what sparked this was trying to rebase and cherry-pick someone elses changes for this MR https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37745
12:02 fluffyfreak: I wanted to test the changes with the latest mesa git code
12:03 fluffyfreak: does anyone else running an RPi get an error from `llvm-config --libfiles --link-shared
12:03 fluffyfreak: ` or am I just the lucky one? :D
12:05 Company: fluffyfreak: https://packages.debian.org/source/sid/mesa says 26.0 depends on llvm-21-dev so I suppose your version won't work
12:07 fluffyfreak: llvm-21-dev doesn't seem be available for RPi Trixie yet so that means anyone trying to build latest on RPi is out of luck by default
12:07 fluffyfreak: I guess that does means I'll have to download and build/install llvm-dev myself
12:07 fluffyfreak: thanks for the help everyone
12:09 Company: you could try just grabbing the package from sid and hope there's no conflicts - certainly faster than waiting for llvm to build on a pi
12:09 fluffyfreak: I've never done that before, no idea how but I'll take a look instead of waiting 6 to 7 hours :D
12:29 fluffyfreak: for anyone following along in this, sadly the llvm-21-dev
12:29 fluffyfreak: .deb has unmet dependencies from SID
12:30 fluffyfreak: I'll take another look after lunch and report back once I've figured out what I need to do. Thanks for all the help so far
13:10 alyssa: fluffyfreak: iirc llvm has nightly deb's
13:11 alyssa: https://apt.llvm.org/
13:11 alyssa: though honestly I switched to Fedora largely just to get newer opencl toolchain ootb
13:16 arnd: tzimmermann: in today's linux-next, I see your 9e422c7122b7 ("lib/fonts: Compare font data for equality with font_data_is_equal()") causes "ERROR: modpost: "__end_rodata" [lib/fonts/font.ko] undefined!" with CONFIG_FONT_SUPPORT=m
13:17 arnd: do you already have a workaround, or should I try to come up with ideas?
13:17 tzimmermann: arnd, i do
13:17 tzimmermann: arnd, see https://lore.kernel.org/dri-devel/4f9b6f94-ed54-4324-a47a-4b379b4e9866@suse.de/T/#m9de3698818890f7887cd7544956b7829e054ea22
13:18 tzimmermann: i'm waiting for nathans reply before going forward, but the patch fixes this on my tests
13:19 arnd: tzimmermann: thanks, testing now as well
14:22 fluffyfreak: alyssa, thanks that got me past that problem. Next one was the LLVMSPIRVLib, so I'm just following the instructions to build that, which still fails...
14:23 fluffyfreak: I think I'll have to leave this until the weekend when I have more time
14:25 mlankhorst: mripard: I've pushed the revert with an ack, would it be imposing to ask for another misc-fixes pull request?
14:26 rodrigovivi: mlankhorst: mripard airlied sima tzimmermann: can I get an ack to get drm_ras/netlink through drm-xe-next please?! https://lore.kernel.org/dri-devel/20260304074412.464435-8-riana.tauro@intel.com/
14:48 mripard: mlankhorst: I'll do one tomorrow
15:09 mlankhorst: rodrigovivi: I don't mind, seems you got the netlink ack to merge it through drm, any specific reason for the drm-xe tree?
15:11 rodrigovivi: mlankhorst: the other xe patches in the series that depend on that: https://patchwork.freedesktop.org/series/155188/#rev11
15:38 zmike: mareko: if you're happy with https://github.com/KhronosGroup/OpenGL-Registry/pull/678 I'll approve it for merge to unblock the implementation
15:55 mareko: yeah it looks good
15:55 zmike: ok
15:55 zmike: gotta double check with nv and make sure they don't want EXT and then I'll get it done
15:56 mlankhorst: rodrigovivi: patches apply to drm-xe-next too
15:56 mlankhorst: misc*
15:58 rodrigovivi: mlankhorst: ops, sorry for not been clear... I want ack from you guys to be able to merge this drm/drm_ras in the drm-xe-next tree along with the other patches... not the other way around
16:10 mlankhorst: rodrigovivi: Yeah it was clear, my question might not have been. I meant to ask why choose drm-xe and not drm-misc if patches apply to both, or is there followup expected immediately after?
17:06 glehmann: In https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39987 I have a integer subgroup op test that crashes on radeonsi, a borderline ub glsl fp edge case test that only fails on intel, and some panvk tests that assert in the backend compiler
17:06 glehmann: I sure love working on NIR
17:06 zmike: strong 💪
17:13 glehmann: the intel fail might be a genuine bug I guess, I have no idea what's going on with the other ones
17:14 rodrigovivi: mlankhorst: Riana and Raag are indeed working on many more error counter and error handling stuff that I believe it might conflict quickly if we put this in -misc and wait the backport in about 3 weeks from now
17:20 glehmann: dj-death: could you help me with the intel piglit fail in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39987 ? or do you know someone else I could ask for help?
17:39 glehmann: great and I can't reproduce the radeonsi issue
17:39 glehmann: mareko: do you have an idea?
17:47 glehmann: actually, another run just passed, so I guess these tests are just too close to the timeout border on this hw?
17:49 mareko: I wouldn't expect radeonsi to be very different from RADV because it's just GLSL -> NIR -> ACO
18:12 karolherbst: not sure if everybody noticed, but we've started a discussion around genAI here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40109 A lot already replied, just mentioning it here again in case people missed it
18:18 mlankhorst: rodrigovivi: in that case, ack :)
18:52 anholt: daniels: what would it take for us to delete old traces from traces-db? I'd love to not be leaving traps for people (including myself) in the repo.