09:59mripard: sima: https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/5e861a695a39263123cdc086934b7336dbe6946d is a bit suspicious to me. Doesn't that break the UAPI?
10:02mripard: the structure size goes from 8 bytes to 16 afaiu, so even the IOCTL definition changes
10:18kode54: cool, and they don't even check the ioctl command size to see if it's missing the flags field as some sort of compatibility check for older software
10:20daniels: it uses the drm ioctl definitions and the drm_ioctl handler, so a) the size is encoded into the ioctl definition, and b) the kernel checks the passed size vs. the size it currently knows about and zero-fills any missing members
10:21daniels: so it's actually perfectly safe to extend ioctls like that, if 0 means the old behaviour
10:33mripard: daniels: oh, TIL, that's cool.
10:33mripard: thanks :)
10:35daniels: np!
12:01stsquad: do the gfxstream guys hang around here at all?
14:38alyssa: anyone care to review a 1-line nir change with no affect on anyone but AGX please?
14:38alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35559
14:38alyssa: thank you c:
14:39zmike: reacted-by
14:39alyssa: good enough for me, assignign to marge, thanks mike :p
14:39zmike: ð€
15:17mareko: karolherbst: do you expect rusticl to be available via distros with the rest of Mesa anytime soon? should we expect that rusticl will be the default OpenCL implementation in distros?
15:18karolherbst: good question. It's already the default on asahi Linux
15:18karolherbst: but I think that's more due to the lack of alternatives
15:20mareko: the reasons don't matter as much as whether it will be packaged by major distros
15:20karolherbst: well it's already packaged
15:20karolherbst: at least in fedora it is
15:21karolherbst: and it works on radeonsi OOTB (as long as you set "RUSTICL_ENABLE=radeonsi")
15:22karolherbst: though not sure it's installed by default...
15:22mareko: what's missing for radeonsi to have it enabled without env var?
15:23karolherbst: add it to the auto group: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/frontends/rusticl/mesa/pipe/device.rs?ref_type=heads#L64
15:23karolherbst: but from a "feature" perspective, maybe passing the CTS would be good?
15:24karolherbst: there are some minor issues left which would be good to figure out before that
15:24mareko: is #[cfg... not a comment?
15:25karolherbst: it's like a C++ attribute
15:25karolherbst: and "cfg" is like #ifdef
15:25karolherbst: "gallium-rusticl-enable-drivers" gets translated to those values
15:26karolherbst: so if -Dgallium-rusticl-enable-drivers=asahi, then "rusticl_enable_asahi" is set
15:26karolherbst: and cfg(rusticl_enable_asahi) enables the code then
15:27karolherbst: so if somebody compiles with -Dgallium-rusticl-enable-drivers=radeonsi, then the array there will list "radeonsi" and so it's enabled by default
15:27mareko: how would you compare Rust to C in terms of productivity given that you have a lot of experience with it now?
15:28karolherbst: don't really have to debug random memory related issues while programming
15:28karolherbst: but it's kinda hard to directly compare, it's more that the compiler warns earlier if you are doing something bad
15:28karolherbst: especially in regards to data ownership and threading
15:29karolherbst: like code with data races won't compile unless you really force it
15:29karolherbst: so it's more like I can focus on the high-level problems and deal less with random nonsense
15:30jannau: it's not installed by default in fedora (or asahi linux). kinda struggling with the question which package has enough of an opencl use case to pull rusticl in
15:30karolherbst: jannau: davinci resolve ð but that's not a package
15:30karolherbst: darktable supports OpenCL tho
15:31karolherbst: there are a few other more scientific tools who do
15:31llyyr: i dont think any distro installs opencl by default
15:32llyyr: it's packaged and available on tumbleweed for ages too
15:32karolherbst: https://osmocom.org/projects/sdr/wiki/fosphor
15:32jannau: ffmpeg has opencl based filters
15:32karolherbst: yeah.. but they aren't necessarily great afaik
15:32karolherbst: but dunno
15:33karolherbst: FluidX3D is a physic simulation thing using CL
15:33karolherbst: there are a couple of use cases but it's all more in the "pro tool" domain
15:34karolherbst: maybe it could be useful for local AI/ML use cases, like translation models... there was also like.. uhm.. digikam supports face detection/recognition via CL and AI models?
15:35karolherbst: that one might be more "avarage user" kind of software
15:35karolherbst: folding at home as well, but no idea who is even using it these days...
15:35karolherbst: anyway
15:36karolherbst: there are some tools here and there
15:36jannau: from fedora POV it probably makes sense to add (reverse) weak dependencies to mesa-libOpenCL for some/all of potential users but the argument for that is weak as long as asahi is the only platform workingout of the box
15:36karolherbst: yeah..
15:36karolherbst: though I think rusticl is in good enough shape these days to think about general enablement
15:37karolherbst: I just don't wnat to force a support burden to mesa driver developers if they aren't fine with it tho
15:39karolherbst: jannau: the big issue wiht that in the past was, that for clover radeonsi _was_ enable by default and it was just broken for most users... and it was so broken it could just hang your system
15:39karolherbst: so I can kinda understand why those deps don't exist these days
15:40karolherbst: anyway.. the main idea was that rusticl should always be safe to install and it's up to distros to decide what drivers to enable
15:40karolherbst: or just pick "auto" and then we decide what we think is safe to enable by default
15:41jannau: clover is disabled since a month or so in the 25.1 fedora packages
15:42karolherbst: it got removed upstream
15:42karolherbst: so yeah
15:42karolherbst: I think I even commented on the PR removing the support
15:42jannau: post 25.1
15:42karolherbst: "clover gets removed" was just the main reason to disable it
15:43karolherbst: should probably also focus more on getting CI testing working out...
16:19llyyr: uhhhh the latest commit to mesa main has an unresolved merge conflict
16:19llyyr: nvm
17:08alyssa: jannau: I kinda want to ship opencl ootb on FAR at least because macOS does so
17:08alyssa: but also I do not use any applications whatsoever with CL so there's that lol
17:35karolherbst: I should at some point check what apple advertises and see how hard it's to add the missing bits