06:55 wens: the drm-misc repo project description on Gitlab still says "drm-misc repo. For now only for issues.
06:56 wens: the latter part should be removed?
07:03 mripard: yes
07:03 mripard: (and arguably, we don't want issues)
07:04 mripard: done, thanks
07:28 javierm:drop his patches adding issues
07:45 wens: thanks!
07:58 mripard: javierm: I think it's a little too early for that, and the issues that are there already are really overlooked
08:00 javierm: mripard :D
08:04 mripard: did I miss something?
08:16 javierm: mripard: no, my comment about dropping patches adding issues was meant to be a joke as an answer to your comment that we don't want issues (to be filled in gitlab)
08:16 javierm: mripard: anyways, if one has to explain a joke means that was a bad one :)
14:15 Lyude: Hm. Something I'm realizing is a bit unclear to me regarding KMS. In drm_plane_helper_funcs.prepare_fb/cleanup_fb(), along with the atomic_update() functions for each mode object type, the display state should be considered immutable when any of these vtable funcs are being called - correct?
14:15 Lyude: ( sima ^ do you maybe have any idea?)
14:34 vsyrjala: we track all kinds ephemeral junk in the atomic state structs (most of which imo shouldn't be there). so enforcing immutability for these in various places is impossible atm
14:35 vsyrjala: the prepare_fb/cleanup_fb probably shouldn't be immutable because the "here's the actual memory" seems like a proper part of the plane's state
14:38 vsyrjala: although even for that it would sure be nice if we had a clear separation of mutable vs. immutable stuff
14:59 Lyude: vsyrjala: gotcha. was mainly asking for the case of rust bindings (currently I have it so that we have mutability up until the actual state swap)
15:54 eric_engestrom: quick PSA: 2 weeks until the Mesa 24.2 branchpoint :)
16:17 karolherbst: I finally fixed the spirv-link stuff for llvm-17+ 🙃
19:37 alyssa: karolherbst: niiice!
19:49 karolherbst: I'm now mostly considering how to deal with it being broken everywhere unless those patches are backported or so... but vendoring all of spirv-tools is also super annoying... I wonder how angry people will be, if we hard depend on a version fixing it while backporting those patches...
19:49 karolherbst: *the paths
19:49 karolherbst: *patch
19:50 karolherbst: or I just check at compile time if that feature is there and print a warning if not at runtime
19:54 Calandracas: wouldn't that require fixing to a specific llvm version too then?
19:55 karolherbst: not really. We can ignore applying that workaround when llvm-17+ is used, but external spir-vs might run into the same issue, though CL doesn't really define how to link spir-v programs together
19:56 Calandracas: nvm, i was thinking of spirv-llvm-translator
21:06 alyssa: karolherbst: my 2c is that llvm-17+ without the spirv-link patches is fundamentally broken (cannot pass CTS), so rusticl should just refuse to probe in that case (once the patches are merged in the appropriate places)
21:07 alyssa: "new Mesa, old spirv-link, nonconformant CL" is a bogus use case imo
21:07 karolherbst: yeah.. but like.. almost nothing depends on the linking 🙃
21:07 alyssa: the CTS does
21:07 karolherbst: not even tools like davinci resolve needs it
21:08 alyssa: maybe I'm a stickler for conformance but these CTS fails are the reason we can't ship rusticl in asahi
21:08 alyssa: (yet)
21:08 alyssa: (presumably we will once the spirv-link patches make it to f40)
21:08 karolherbst: rusticl doesn't advertize being conformant there anyway
21:08 karolherbst: ROCm isn't even conformant in the first place
21:08 karolherbst: and nobody really cares
21:09 karolherbst: but yeah.. it's an issue, however, what I could add is, if the linking fails to due this bug, I could just add the info message in the compiler output stating: "please update spirv-tools to get this to compile" or something
21:10 alyssa: that's an option, ye
21:10 karolherbst: and maybe never advertize conformance if I know at runtime that dependencies aren't new enough
21:10 ccr: a convention of non-conformists?
21:10 karolherbst: because iris 12th gen currently still does
21:10 karolherbst: even though it would fail to link
21:10 alyssa: re ROCm... do I think I'm better than AMD? /* no comment */
21:10 karolherbst: :D
21:11 karolherbst: I should file for conformance on radeonsi honestly
21:11 alyssa: yas
21:11 karolherbst: spirv-tools patched on my testing system... let's gooo
21:11 karolherbst: I missed those "100%" runs honestly
21:13 karolherbst: and maybe I should fix the remaining bugs on asahi as well.. and I think there might be... one? or two?
21:13 karolherbst: maybe none?
21:13 Calandracas: Where can I find these spirv-tools patches?
21:13 karolherbst: https://github.com/KhronosGroup/SPIRV-Tools/pull/5534
21:13 Calandracas: thanks
21:13 Calandracas: one "bug" on asahi is that it fails to cross compile :P
21:13 karolherbst: heh
21:14 karolherbst: what bug was that, because I've fixed a couple of weirdo compilation issues with rusticl and the opencl code
21:14 karolherbst: I actually did a lot of bug fixing the lsat couple of weeks
21:14 alyssa: karolherbst: there's still the addsat bug i think, but yeah
21:15 karolherbst: ahh.. that one
21:15 Calandracas: https://gitlab.freedesktop.org/asahi/mesa/-/issues/41
21:15 karolherbst: with the linking bug fixed, I think even v3d is almost conformance
21:15 karolherbst: though
21:15 karolherbst: it doens't support imagew
21:15 karolherbst: *images
21:15 Calandracas: src/asahi/clc/meson.build:4:17: ERROR: Tried to tied to mix a host machine library ("asahi_compiler") with a build machine target "asahi_clc" This is not possible in a cross build.
21:15 alyssa: karolherbst: I'll fix the sat thing if you fix the spirv link thing
21:15 alyssa: Calandracas: yeah, I know. It's not a bug. Sorry.
21:16 karolherbst: "just get arm runners"
21:17 karolherbst: or use qemu-user and look at those 2 hour compile times
21:17 Calandracas: yeah, oh well :P
21:18 alyssa: yes, I knowingly broke cross compilation
21:18 karolherbst: it's a pain anyway
21:18 alyssa: in exchange for that, you got gl3.2+, es3.2, and vk1.3 support
21:18 alyssa: so..
21:19 karolherbst: you could also give up your sanity and just write the lowering with nir_builder
21:19 alyssa: no.
21:19 alyssa: Calandracas: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9080 This is the upstream issue
21:20 Calandracas: Okay thanks for the info
21:20 karolherbst: it's a meson bug (tm)
21:31 alyssa: Calandracas: I'm hopeful future Meson will fix things. In the mean time, unfortunately cross compiling isn't going to work without hacks and ... yeah. It was the right call, 100%, but it's not without a sharp corner. alas, big picture! :)
21:31 alyssa: we make *extensive* use of opencl within the driver to implement things like geometry shaders https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/asahi/lib/shaders/geometry.cl?ref_type=heads
21:32 karolherbst: I wonder if meson even could magically compile it for both the target and the host, because that _might_ lead to situations, but probably fine
21:32 karolherbst: that UNROLL macro tho
21:33 karolherbst: you wanna C++ for OpenCL so you can use templates intead :D
21:33 Calandracas: that unroll macro looks like a job for C++ for OpenCL templates :P
21:33 karolherbst: well...
21:33 karolherbst: we _could_ support it, just initializers and finalizers are pain
21:33 karolherbst: but as long as the spirv doesn't use that?
21:33 karolherbst: should work (tm)
21:34 HdkR: karolherbst: That's part of what the meson fix to that bug is doing. Compiling the tools for both the host and the guest architecture. There's a PR for it somewhere :)
21:35 karolherbst: nice
21:36 HdkR: https://github.com/mesonbuild/meson/pull/12022
21:36 alyssa: Calandracas: blender works because i am unhinged ;P
21:36 alyssa: (that unroll macro exists because of blender.)
21:39 Calandracas: i really like C++ for OpenCL, but the ahead of time compilation is a pain i guess
21:44 Calandracas: https://codeberg.org/calandracas/opencl-samples/src/branch/main/printf < how I do offline compilation with OpenCL for C++
23:27 karolherbst: uhh.. "images_cl_read_write_images 2Darray" is a regression I haven't taken care of yet.. oh well.. tomorrow