05:02 mlankhorst: pixelcluster: Let me take a look! Lets merge it indeed
07:36 javierm: tzimmermann: sorry I missed your message about e-ink panels
07:37 tzimmermann: no worries
07:37 javierm: tzimmermann: the drivers/gpu/drm/tiny/pixpaper.c driver is for the PIXPAPER-426-M (https://www.open-ep.org/shop.html)
07:38 tjaalton: karolherbst: well that was a lot to read.. anyway, re: requiring clang-22 is fine, this would be 26.2+ material for me (debian/ubuntu) anyway
07:39 tjaalton: I'm not backporting 26.1 anywhere
07:39 tzimmermann: javierm, nice. i didn't know these where so easy to get
07:41 javierm: tzimmermann: and drivers/gpu/drm/tiny/repaper.c driver (from where I took the drm_fb_xrgb8888_to_mono() helper) is for pervasive e-inks
07:41 javierm: https://www.pervasivedisplays.com/product/#epds-e-paper
07:41 javierm: tzimmermann: I don't have any e-ink, but I looked some time ago because I wanted one with Linux support
07:42 tjaalton: as for spirv-llvm-translator being behind on debian; the maintainer seems to be on leave
07:43 tzimmermann: cool! thanks, javierm. i think i'll try to get some of those displays
07:44 javierm: tzimmermann: cool, let me know how it goes. I may get one too
15:15 alyssa: oof, derivatives are legal in divergent control flow as long as quads are uniform. that's a nasty corner.
15:16 HdkR: ooo, spicy
15:27 mareko: do you mean as long as control flow is quad-uniform?
15:30 alyssa: mareko: yeah
15:57 karolherbst: alyssa: I don't want to turn all of libclc into custom targets generating *.bc files and... 😭 I think before can compile clc files sanely, we probably want proper meson integration for OpenCL targets so it's not _that_ painful, could even simplify all the stuff we currently have?
16:05 alyssa: karolherbst: Yeah, dcbaker's talked about that
16:05 karolherbst: it doesn't help that LLVM passes like 20 compiler flags in addition..
16:06 karolherbst: well maybe not 20
16:06 karolherbst: oh wait.. on the 23 branch they added a bunch
16:06 dcbaker: karolherbst: yeah, we're in the process of adding the underlying support for more than two targets to Meson, and things like CL and SPIRV are things I have in mind
16:06 karolherbst: ahh cool
16:09 karolherbst: anyway.. for now I'll try to get a proper cmake wrap going but that kinda fails :'(
16:11 karolherbst: uhhh...
16:11 karolherbst: dcbaker: if I want to write a wrap file, but the projects root is in a subdirectory of the wrapped project, how would I declare that?
16:12 dcbaker: Oh, I think there's a way to do that... let me look
16:12 dcbaker: ah, I think you can do that with the directory field in the wrap file, something like llvm-project/llvm
16:13 karolherbst: huh... interesting, will try that. I thought it's to name the directory
16:13 dcbaker: It's so supposed to point to the root source directory
16:14 dcbaker: If that doesn't work I'll look more, but just reading the docs that's supposed to work
16:14 karolherbst: how pushing an llvm tree is going:
16:14 karolherbst: error: RPC failed; HTTP 503 curl 92 HTTP/2 stream 9 was not closed cleanly: STREAM_CLOSED (err 5)
16:14 karolherbst: send-pack: unexpected disconnect while reading sideband packet
16:14 karolherbst: Writing objects: 100% (6810036/6810036), 3.80 GiB | 25.97 MiB/s, done.
16:14 karolherbst: Total 6810036 (delta 5636863), reused 6747263 (delta 5584509), pack-reused 0 (from 0)
16:14 karolherbst: fatal: the remote end hung up unexpectedly
16:17 karolherbst: yeah.. that's not gonna fly :'(
16:24 DragoonAethis: karolherbst: try https://docs.github.com/en/get-started/using-git/troubleshooting-the-2-gb-push-limit
16:24 DragoonAethis: Pushing every Nth commit to partially load the history on the remote works pretty well
16:25 karolherbst: yeah... but do I want to pusha 4GiB project to our gitlab?
16:25 karolherbst: but yeah I could chunk it...
16:56 karolherbst: dcbaker: "WARNING: Subproject 'mesa-libclc' did not override 'mesa-libclc' dependency and no variable name specified" any what I do wrong there?
16:56 karolherbst: the cmake project is kinda a disaster
16:57 dcbaker: yeah, the CMake works in some cases, but not in every case.... I'm assuming there's a libclc target and not a mesa-libclc target in the CMake?
16:57 karolherbst: maybe I should try the "move it into the tree" approach and wrap the meson project...
16:57 dcbaker: You might be able to add [dependencies] mesa-libclc = libclc?
16:57 karolherbst: ahh... maybe
16:58 dcbaker: I'm not sure exactly how the cmake wrap stuff all works
16:58 karolherbst: mhhh
16:58 karolherbst: it renames the targets...
16:58 karolherbst: let me check out the generated meson.build file..
16:59 karolherbst: ohh there is a libclc target..
16:59 karolherbst: dcbaker: where do I have to put the dependencies thing? In the wrap file? That doesn't seem tow rok
17:00 dcbaker: karolherbst: sorry, I was going off of memory, the section is called `provides`
17:00 dcbaker: err, provide
17:00 dcbaker: https://mesonbuild.com/Wrap-dependency-system-manual.html
17:00 dcbaker: gah, https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section
17:00 karolherbst: Variable 'libclc' in the subproject 'subprojects/mesa-libclc' is not a dependency object mhhh
17:01 karolherbst: dcbaker: I kinda thought it's for the reverse tho? To provide dependencies for the subproject?
17:02 karolherbst: but let me try to rename the target..
17:03 karolherbst: the entire project is cursed: ddd_custom_target( libclc ALL )
17:03 karolherbst: *add_custom_target
17:05 dcbaker: Oof, that's all just hand-rolling OpenCL support in CMake... I guess we could do that with generators... maybe?
17:06 dcbaker: I might try that later and see if I can get generators to do what we want
17:06 karolherbst: yeah....
17:07 karolherbst: and the generated targets that provide the spirv files are custom_tgt_259 and custom_tgt_519 :)
17:08 karolherbst: and then meson adds a custom target library_spirv64_mesa3d__spv that outputs library_spirv64_mesa3d__spv.h ...
17:08 karolherbst: it's all kinda cursed
17:09 karolherbst: maybe I should just add spir-v files to mesa 🙃
17:09 dcbaker: ugghhhh
17:09 karolherbst: if the dependency wasn't found
17:09 karolherbst: then just use the in-tree spirv files..
17:09 karolherbst: like it's two files + a pc file 🙃
17:10 karolherbst: anyway, I don't think I can wrap it with current meson
17:23 karolherbst: maybe building the thing in meson is the easiest solution...
17:24 karolherbst: it's a little cursed but shouldn't be tooooo terrible...
17:39 HdkR: Does meson support cross-compiled subprojects yet? :)
17:40 dcbaker: I think that will work in 1.12, although there may be a few more things to do
17:40 dcbaker: Which is in RC right now
17:41 dcbaker: There has been a significant amount of work from bonzini on getting that working
17:42 HdkR: Nice, so FEX switching to meson might actually be viable now :D
21:32 airlied: agd5f: just pinging here as well, I dropped your PR for fixes due to missing signoffs
21:32 agd5f: yeah, will send a fixed up PR now
21:33 agd5f: Those patches required significant work to backport so Leo did the backport and provided me with a branch and I promptly forgot to -s when I cherry-picked them
21:33 agd5f: sorry about that
21:50 agd5f: airlied, sent a new PR
22:22 airlied: agd5f: thanks!
22:48 FireBurn: airlied: Slowly progressing now - the thing I thought was random data wasn't - now that's fixed I'm wiring stuff up
23:02 karolherbst: okay soo.. normally I'm a big fun of using uint8_t return types, but I want to inform you that the result gets integer promoted to int32_t, you're welcome
23:02 karolherbst: nv30 has an issue there, but also vc4: "float_to_ubyte(storage_color[0]) << 24" :')
23:02 karolherbst: that's technically UB
23:21 airlied: karolherbst: also fun fact clang and gcc disagree on how that all works as well
23:21 airlied: so best just stick to 32-bit everywhere :-P
23:21 karolherbst: yeah...
23:21 karolherbst: I think GCC actually defines some of that stuff
23:22 airlied: well the both define is, just different
23:22 karolherbst: nice
23:22 airlied: https://reviews.llvm.org/D72742 is you really want to give up
23:22 karolherbst: ohh I've seen that one lately
23:22 airlied: I think the x86-64 stds clarified it at least
23:24 karolherbst: I think I wrote somewhere that "uint64_t some_var = 1 << 31" on gcc gives you 0xffffffff80000000
23:24 karolherbst: so somebody pointed that one out