15:18karolherbst: alyssa: okay, seeing this c11_atomic validation error also here. Seems to be pretty new as in, probably last week added it.. will bisect it later
15:19pq: Where is the format of CRTC "BACKGROUND_COLOR" documented?
15:21pq: in docs.kernel.org I only found vague references to DRM_ARGB64_PREP*(), but these don't seem to exist in libdrm or UAPI headers.
16:17karolherbst: alyssa: I've fixed it: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42277
16:18alyssa: karolherbst: thx
16:18karolherbst: ohh maybe I should also call nir_intrinsic_set_write_mask...
16:20karolherbst: ehh kinda pointless
16:21karolherbst: atomic_swap doesn't have that index anyway
16:30karolherbst: zmike: so I'm getting "test_image_streams: ../src/gallium/drivers/zink/zink_resource.c:3447: resource_object_add_bind: Assertion `!"zink: all buffers should have this bit"' failed." for 2d from buffer images. Which is a regression from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41734
16:31zmike: ...what bind is it trying to add
16:32karolherbst: 0x10000000
16:32karolherbst: it's ZINK_BIND_MUTABLE I think
16:33zmike: the fuck
16:33karolherbst: backtrace: https://gist.githubusercontent.com/karolherbst/649c20c015546ed3046ca6bead1d56f1/raw/039f646a6c98f013b639019722b0b6ed035876d7/gistfile1.txt
16:34karolherbst: I suspect something with the cursed 2d from buffer handling is weird there
16:34karolherbst: but the code is kinda difficult to understand...
17:18zmike: your bisect was off https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42278
17:19karolherbst: ohhh...
17:20zmike: AI wins this round
17:20karolherbst: :'(
17:20karolherbst: yeah seems to fix it
17:22karolherbst: oh heh.. that's a commit right after the MR...
17:22karolherbst: yeah maybe I messed the bisect up or something
18:14karolherbst: alyssa, jenatali: any thoughts of pulling in libclc spirv binaries into the mesa tree + instructions on how to build it yourself if you really want to? I'm kinda considering creating an LLVM fork (lol) just to have a tree where we can point people to and say "if you don't want to run into random bugs, use this, otherwise unsupported"
18:15jenatali: karolherbst: I'm in favor. That would simplify my build environment so much
18:15alyssa: Distros will hate us. Don't do it.
18:16alyssa: And more to the point, distros will strip it off (cursing us) and then ship the unsupported (read: broken) configuration instead and then we'll get the bugs.
18:16karolherbst: they can build our fork
18:16alyssa: They won't
18:16karolherbst: they can use the binary we have in our tree :P
18:16alyssa: They won't
18:17alyssa: tjaalton: ping
18:17alyssa: ^
18:17karolherbst: we can also pull in all of CLC and build it inside mesa and require clang :P
18:18karolherbst: but yeah... I know it sucks for everybody, but I'm also getting tired if I have to track down libclc regressions with each version
18:20alyssa: pulling in libclc itself (source) and requiring clang would be fine for linux downstreams, yes
18:20alyssa: well
18:21alyssa: someone will complain about vendoring dependencies but it's a much lesser sin and we have good reasons if we're going to be maintaining it ourselves and diverging and such
18:21karolherbst: some distros will complain, lol
18:21CounterPillow: aren't meson wraps sorta for that?
18:21CounterPillow: and then specify an exact version in the deps
18:21karolherbst: could also have it be a git submodule (ðŸ˜) that points to our llvm fork (ðŸ˜)
18:22karolherbst: the issue is that upstream is just broken in weird ways with different bugs depending on the version
18:22karolherbst: and it's... just easier to have a branch with fixes
18:30dcbaker: karolherbst: sounds like you want to be the LLVM stable maintainer :D
18:30tjaalton: alyssa: yes?
18:30karolherbst: dcbaker:.... no?
18:30alyssa: tjaalton: see discussion starting 4 minutes before my ping
18:30alyssa: iirc you're the debian mesa maintainer
18:30dcbaker: I mean, maintaining your own branch with fixes sounds like what a stable branch maintainer does
18:32karolherbst: heh
18:32karolherbst: well it's only for libclc, which is kinda small in comparison :P
18:32karolherbst: I would probably ditch all the other things
18:33karolherbst: alyssa: maybe the solution is: "if you use any other binary, we won't claim conformance"
18:34karolherbst: the pain part is that the libclc binary doesn't contain any version information, so we can't even guess if it's fine or not...
18:34karolherbst: Maybe we maintain a list of hashes for "good" versions 🙃
18:34karolherbst: I hate how I only have bad solutions for this
18:38tjaalton: well, the problem with libclc right now is that building a new major version of llvm requires two passes, the first is used to build libclc. so if this would get rid of that (mesa building it instead) then I guess it would be a win
18:38karolherbst: well that's just a limitation of how you build llvm tho
18:39tjaalton: I don't see any other users of libclc in the archive
18:39tjaalton: true
18:39karolherbst: clvk also uses it
18:39karolherbst: and I think pocl as well? But they both might use llvm forks :')
18:40karolherbst: tjaalton: So.. if mesa could be pointed to a llvm fork with libclc patches and then build it alongside everything else, that would be acceptable?
18:40karolherbst: but that would require clang usage at least for the libclc bits
18:40alyssa: tjaalton: IIRC Debian has policies against vendoring stuff, but I guess if nothing else in the archive uses libclc, if we forked (at a source level) we just become the new upstream in effect and the existing libclc package is sunset I guess..?
18:40karolherbst: and could create an odd situation where you build mesa with gcc _and_ clang
18:40tjaalton: we already use clang for other bits
18:41karolherbst: mhhh.. right
18:41alyssa: karolherbst: clang is already a hard req for intel/asahi/panfrost/nvk
18:41karolherbst: ahh
18:41karolherbst: okay
18:41karolherbst: and I guess the cmake integration is good enough in meson so it can just build a cmake project?
18:41karolherbst: because how libclc is built now is that it uses a C compiler for the clc files :)
18:42alyssa: karolherbst: how hard would it be to copy just the .cl's, nothing else, and build with meson + mesa_clc + etc?
18:42alyssa: are they doing weird stuff?
18:42karolherbst: like the global cmake C compiler
18:42karolherbst: yes?
18:42tjaalton: rust bits are allowed to be vendored, and having them as such does make things easier as the packaged crates can be in a weird state
18:42alyssa: interesting, ok
18:43tjaalton: it's not a hard-no
18:43alyssa: ack
18:44karolherbst: I guess if the reason is "you get a bug free version that works with mesa" is probably a good arugment
18:45dcbaker: karolherbst: looking at it I'd be surprised if Meson's CMake integration works, but I'm opened to being surprised
18:46tjaalton: karolherbst: I'd prefer it all be within the same tree, because package builds can't just go download randomware from the internet
18:46dcbaker: otherwise, I think I can pretty easily open code it with generator
18:46karolherbst: tjaalton: what if the fork is hosted on our gitlab?
18:46dcbaker: tjaalton: is it fine if it's in the same dist package?
18:46karolherbst: could even tag releases...
18:47dcbaker: because Meson can add subprojects to the diest tarball
18:47tjaalton: well it'll end up vendored locally in the package anyway I guess
18:47alyssa: karolherbst: ok, I have a much more radical idea -
18:48alyssa: vtn_bindgen2 provides existing infrastructure in Mesa to wrap opencl functions (not kernels) as nir_builder routines
18:49tjaalton: so as long as it can consume a local dir in the source root, for instance.. that would work
18:49alyssa: Why don't we just copy the actual /implementations/ from libclc and bind with vtn_bindgen2
18:49alyssa: then in spirv_to_nir, just do libclc_frcp() or whatever and delete all of the spirv linking / name mangling / etc garbage
18:49alyssa: be in control of our destiny
18:50karolherbst: mhhhhhh
18:50karolherbst: maybe
18:50karolherbst: I have to think about it
18:50alyssa: Not as easy as just forking shit but a much more.. Mesa-native long-term approach
18:52karolherbst: yeah..
18:52karolherbst: maybe
18:52karolherbst: I'll have to play around with the idea
18:52alyssa: We can do that incrementally
18:52karolherbst: but I also kinda want to make it simple enough to pull in upstream llvm changes in
18:53alyssa: Port one function at a time - add in the .cl impl, add 2 lines to handle_special to call it, delete the REMAP line for it
18:53alyssa: like all the pieces are already there
18:54karolherbst: could do it for the broken stuff first I guess...
19:48mareko: ok
21:26karolherbst: alyssa: mhh.. how would we deal with overloading?
21:27karolherbst: though I guess could add more glue code that checks the input args...
21:33karolherbst: alyssa: ohh btw.. any opinions on stuff like this? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41970
21:34karolherbst: that's also going to become relevant if we move it into vtn_bindgen
22:32alyssa: karolherbst: that's fine, the same solution would work there too
22:32alyssa: overloading is.. more problematic. How bad is it in practice though?
22:33karolherbst: mhhh.. well the same builtin name is used for fp16/fp32/fp64 scalar/vec2/3/4/8/16 versions
22:33karolherbst: though many CL builtins just wrap around scalar impls anyway...
22:34karolherbst: so maybe this issue goes away if we just diverge hard enough from upstream, but....
22:42alyssa: vec size is best handled on the nir side. bitsize is more problematic indeed.
22:43elibrokeit: 14:34 <karolherbst> the pain part is that the libclc binary doesn't contain any version information, so we can't even guess if it's fine or not...
22:43elibrokeit: this can be your first maint fix!
22:44karolherbst: if I already maintain my own fork, I won't have to bother with versions..
22:45elibrokeit: I mean as the upstream stable maintainer of course :P
22:46karolherbst: the issue isn't that
22:46karolherbst: the issue is, that llvm upstream breaks things and we'd have to clean it up after the fact, so I'd rather only see users using versions that we signed off on
22:47karolherbst: like optimally LLVM can just run tests in CI or something
22:52karolherbst: really.. I just want to point to a tree that is upstream LLVM from some git hash + fixes and tell everybody to use that