00:06 soreau: you can install a cmake subproject, if that's what you need
00:10 karolherbst: soreau: I do need it, but it doesn't seem to work at all
00:10 karolherbst: or maybe I'm using it incorrectly
00:10 soreau: karolherbst: there was some bug with certain versions of meson recently-ish
00:11 karolherbst: mhh
00:11 karolherbst: I've tried with 1.11.1
00:14 soreau: https://github.com/WayfireWM/wayfire/blob/master/subprojects/yyjson.wrap usage: https://github.com/WayfireWM/wf-json/blob/70039e13cdeaebd8ec498ed30bf5ab91c2e313ec/meson.build
00:17 karolherbst: soreau: and that installs targets from json?
00:17 karolherbst: sub_proj I mean
00:18 soreau: karolherbst: well in this case, the .wrap file and the subproject that uses it are both in project/suprojects/
00:18 soreau: they're super projects now, I guess :P
00:18 karolherbst: so the meson build system will install files from the subprojects on "ninja install"?
00:19 soreau: well you have to dep on the subproject in some meson.build for the root project
00:19 karolherbst: but that's not gonna install files from the subprojects, would it?
00:20 karolherbst: I don't mean "install for the purpose of building against it", I mean "install it in the meson prefix the build targets"
00:24 soreau: I think it should do what the subproject does
00:24 soreau: so if cmake project installs, then meson/ninja would install it
00:24 soreau: but idk if it's statically linked
00:25 soreau: it should be possible to do what you want, though
00:26 soreau: karolherbst: maybe I could be of more help if you could detail a bit more about what you're expecting to happen
00:26 karolherbst: I want to install targets of the cmake subproject
00:27 soreau: does the cmake project install itself 'normally' and when you dep on it, is the resulting lib installed? if yes to both, then I expect it would install the cmake project too
00:27 karolherbst: I don't want to use it as a dep
00:28 karolherbst: because there is nothing to use as a dep
00:28 soreau: ah
00:28 soreau: so you just want to install the subproject in tandem with the main project
00:28 karolherbst: it's building SPIR-V files I want to install and wrap it with a meson project to abstract the build system away
00:29 karolherbst: but I could also just add a build script and tell people how to build it...
00:29 soreau: well just use dependency() and see if that's enough?
00:29 karolherbst: yeah.. maybe I should try that, thought he meson project itself doesn't really build anything... I was just wondering if I could wraps a cmake project with meson...
00:29 soreau: if you're gonna do a script, meson supports those in install too IIRC
00:31 karolherbst: the cmake project is a little cursed, compiles CL file to llvm bitcode, links it and the converts it to SPIR-V
00:32 soreau: ok, so you apparently cmake_opts.set_install(true)
00:34 soreau: I'd assume you'd write the .wrap file, put it in subprojects/ and then do this dance with set_install() https://github.com/WayfireWM/wf-json/blob/70039e13cdeaebd8ec498ed30bf5ab91c2e313ec/meson.build#L8-L12
00:34 karolherbst: yeah.. but set_install didn't do anything
00:35 karolherbst: though I think it's the fault of the cmake project
00:36 karolherbst: because it doesn't install targets...
00:36 karolherbst: it installs files
00:36 karolherbst: and does weird dependency stuff
00:46 soreau: hm.. ymmv ;)
00:47 soreau: of course if all else fails - script it
00:49 soreau: once upon a time, I installed vulkan to a nonstandard prefix.. it was painful to say the least
00:49 soreau: and why does cmake try to ignore/reinvent pkgconfig.. ugh
01:42 elibrokeit: <soreau> and why does cmake try to ignore/reinvent pkgconfig.. ugh
01:42 elibrokeit: do you seriously want the answer to this?? :D
01:42 soreau: no, it was more of a 'dont get me started' prefix :P
01:44 elibrokeit: too bad. cmake supports Windows conventions for installing two copies of your software, one built against the release CRT and one built against the debug CRT. for Reasons™, cmake find_package() -- that's the NIH dependency() thing -- will check for both but prefer the version that is linked again the same CRT as your current cmake build directory
01:45 elibrokeit: for this reason, pkgconfig "can't support the things that our customers want therefore we will shun pkgconfig" -- the CMake devs
01:46 elibrokeit: now you know...
01:47 soreau: that is a really bogus reason
01:47 soreau: at least now I know
02:08 karolherbst: okay.. I already hate the llvm-23 libclc.. so apparently you can only build a single target at the same time...
02:10 karolherbst: I'll get something done tomorrow.. *sigh*
07:41 pq: hmm... where did the spelling "uAPI" come from? Isn't "UAPI" more consistent?
07:44 emersion: i used to parse it (incorrectly) as µAPI
08:30 pixelcluster: mlankhorst: hey remember my dmem cgroups patchset? :P
08:31 pixelcluster: last revision you (rightfully) requested we make some IGT tests for it
08:32 pixelcluster: and I did - there were already movements towards dmem cgroup tests in IGT, and I based my tests on those, but then that work stalled and that's how it's been for months :/
08:33 pixelcluster: I'm wondering if we could make some progress on the patchset if I send a rebased v7 (i think it's v7?)
08:33 pixelcluster: to not have it hang in limbo for forever
11:56 pac85: gfxstrand: I was trying to understand the following loop and it seems like it's code you wrote https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_syncobj.c?ref_type=heads#L1133
11:56 pac85: So, fences can be null for syncpoints of jobs that have not been submitted yet, and I guess the idea with this loop is to add a callback to the existing fences so that when those are signaled it will check if other fences have come up? But what if a syncobj is sent where all the fences are null? In that case no callback is added and we go straight to the schedule_timeout call which is gonna wait for the full timeout (potentially
11:56 pac85: indefinitely) since nothing is gonna wake us up.
11:57 pac85: she might be on the side of the globe that's still sleeping so if anyone else understands this code please chime in.
12:38 pixelcluster: pac85: look at drm_syncobj_fence_add_wait
12:39 pixelcluster: if WAIT_FOR_SUBMIT is set, that function is called for every entry in the syncobj
12:40 pixelcluster: if drm_syncobj_fence_add_wait fails to find a fence to use (=the entry's fence remains NULL), the entry is added to the syncobj's cb_list
12:40 pixelcluster: in drm_syncobj_add_point, the cb_list is iterated over and the processes associated with that list entry are explicitly woken up
12:43 pixelcluster: fwiw i'm pretty sure this pattern is used in lots of drivers
12:46 pac85: pixelcluster: aaahh thx that makes sense
15:01 FireBurn: The wall has fallen :D
15:51 karolherbst: eric_engestrom: any concerns adding a dependency on stable branches? I want to create a libclc fork to give users blessed versions of it that contain fixes and actually work (there are a couple of issues with it in llvm-22 and llvm-23). Sadly I think that will depend on clang-22 and not sure if that's a no go for many distributions that e.g. ship
15:51 karolherbst: mesa 26.1 or not
17:50 elibrokeit: karolherbst: Debian testing has clang 22, stable-backports has mesa 26.1; that may influence your decision
17:51 karolherbst: elibrokeit: good thing is, that you can build once and use the same build in older versions, it's just a build time dependency
17:53 karolherbst: in the end it's just some spirv files and I could even provide them as downloads, because it really doesn't matter all that much in practice
17:57 DragoonAethis: karolherbst: mixing builds between distro versions is probably not going to happen upstream though
17:57 DragoonAethis: if you can vendor those files for the branch, no action would be needed from upstreams either
17:58 karolherbst: well I do want to be able to push updates out without updating mesa.. but we could also include those files in mesa and then distributions would want to build it themselves anyway...
17:59 karolherbst: maybe I should check if I can build with an older clang version...
18:02 karolherbst: ohh seems like even clang-20 is fine
18:02 elibrokeit: iirc Debian can be pretty arbitrarily strict about "generated sources"
18:02 karolherbst: uhh maybe
18:02 karolherbst: the build system is weird
18:03 elibrokeit: like, "we need to recreate man pages from scratch if you ship a pandoc generated one in your dist tarball" levels of strict
18:03 karolherbst: well it's code running on a GPU..
18:04 karolherbst: so I can kinda see why some want to be strict there
18:04 elibrokeit:despises pandoc for many many reasons, which also includes the reason of "it requires compiling and installing hundreds of distro packages just to get one program", thank u haskell
18:05 DragoonAethis:agrees
18:15 karolherbst: mmhh yeah no... it will require clang-22
18:17 elibrokeit: is it practical to just sort of wimp out and tell anyone without new enough clang "we're gonna use your system libclc, it may or may not work correctly, you have been warned"?
18:17 elibrokeit: then it becomes a Debian problem if Debian doesn't have clang 22 available
18:17 karolherbst: elibrokeit: the issue is, that I get the bugs, not debian
18:19 karolherbst: but then again.. it's just three files: 2 spirv files, one for 64 and 32 bit GPUs and one pkgconfig one
18:19 elibrokeit: mandatory "we will automatically-close all issues that don't contain `/usr/bin/mesa-build-info` output"
18:19 elibrokeit: this is anyways probably a good idea
18:19 karolherbst: well that never worked in practice
18:19 karolherbst: the issue is, that debian isn't going to fix this
18:20 elibrokeit: if the issue is that Debian is not going to fix things no matter what you do, then you're screwed because any possible solution you think up will be patched out by them
18:20 karolherbst: like what would debian do if a user files a bug with "you use upstream libclc instead of mesa-libclc, it's broken, pls fix"
18:21 karolherbst: elibrokeit: yeah but if debian patches it out, it's debian actively making a decision to ship with broken stuff
18:21 elibrokeit: they could always cry themselves to sleep
18:21 karolherbst: which is kinda an awful thing to do if you ask me
18:22 elibrokeit: the Debian Developers may choose to cry themselves to sleep instead of shipping working software. that's their choice.
18:22 karolherbst: well
18:22 elibrokeit: it's not upstream's job to force them to do the right thing
18:22 karolherbst: it's not, and that's the issue
18:22 karolherbst: they make a choice to harm the reputation of a project and never have to deal with the costs
18:22 elibrokeit: it's upstream's job to draw a line in the sand and say that you aren't going to provide help to users who break it
18:22 karolherbst: in case they would decide to ship it knowingly broken
18:23 karolherbst: elibrokeit: yeah but again, this never does anything in practice
18:23 karolherbst: users end up with something broken
18:23 karolherbst: nobody is helped
18:23 elibrokeit: yes, and you can respond to all bug reports that are from Debian users with "unfortunately debian ships a broken version of the software, we can't help you, go complain on the Debian bug tracker"
18:24 karolherbst: sounds like the experience you get if you go to an agency and they just say you visited the wrong one
18:24 elibrokeit: it's not *about* helping users, it's about the fact that you lack any ability to solve their problem and therefore *at least you can direct them to the right complaints department*
18:25 karolherbst: I just wished we wouldn't have that problem
18:25 karolherbst: sounds dysfunctional tbh
18:25 alyssa: elibrokeit: my entire website is just ad hoc scripts strapped to pandoc, does this horrify you
18:26 karolherbst: maybe I should just make rusticl download the spirv files 🙃
18:27 elibrokeit: the thing about Debian that people never seem to understand, is that the entire purpose of Debian is to produce an operating system on the theory that known bugs are better than unknown fixes that require you to adapt to a menu option that uses slightly different grammar to change how it describes the same feature
18:27 elibrokeit: Debian is *stable* because *it doesn't break your workarounds* except on a strictly regulated schedule
18:27 elibrokeit: therefore Debian is *suitable for avoiding enterprise retraining seminars*
18:28 elibrokeit: if that isn't your single overriding goal then you *should not be using Debian*
18:31 daniels: Debian requires that generated files _can_ be generated, not that they _must_ every time
18:32 karolherbst: elibrokeit: sure, but it's a khronos API that is implemented and people expect correctness
18:32 karolherbst: nobody is going to workaround this
18:32 daniels: tjaalton: ^ thoughts on the mesa src.deb bundling clc spv?
18:33 daniels: (the good thing is that we don’t need to speculate about the arbitrary decisions of an amorphous blob, we can just … ask the guy)
18:33 karolherbst: but yeah.. if it's acceptable to just ship spirv files from out gitlab or wherever, that's fine by me
18:33 elibrokeit: daniels: and if it can't be generated because the dependency is only in Debian sid, then what?
18:33 daniels: elibrokeit: I believe that would be fine
18:33 elibrokeit: my personal answer to that question is "don't think about it, that's Debian's problem"
18:34 daniels: Debian is much more pragmatic than it gets made out to be
18:34 karolherbst: I just don't want to create a situation that gets impossible to fix due to project rules
18:35 karolherbst: and the good thing here is that there is no runtime dependency anyway
18:36 elibrokeit: daniels: I'm perhaps a bit salty about Debian because Debian developers have, on a number of occasions, armtwisted upstream projects into dropping stuff like pre-generated manpages
18:36 elibrokeit: saying for example "by policy we cannot and will not use this, therefore please drop it from your source tarballs. distros hate when you include pregenerated manpages in source tarballs"
18:38 elibrokeit: clearly, whatever the Debian project requires, the actual developers who implement the Debian project are much less pragmatic than "the project" allows them to be
18:38 karolherbst: yeah well my hope is that "you can only build it with clang-22 sooo... " is a strong enough argument that they either ship binaries build against newer versions on older (which is fine, because it's just three blobs of data) or they just ship pregenerated ones
18:38 karolherbst: but it's also pointless to discuss what ifs
18:38 elibrokeit: thus i would actually argue that Debian is exactly as un-pragmatic as I claim them to be, since Debian is what its developers implement it to be
18:39 karolherbst: anecdotal evidence doesn't really help tho
18:39 karolherbst: I'm more concerned about rules that make them ship upstream libclc with known bugs and making it my problem
18:41 karolherbst: but the entire discussion was on the hypothesis that there is a rule in place that would prevent them from shipping the binaries I'd like them to be shipped
18:45 karolherbst: and "just blame debian, because the solution I picked made them do something I don't want them to do" isn't a great outcome anyway
18:48 daniels: Debian is thousands of developers and tens of thousands of packages, and they are not all of a single kind
18:49 daniels: *mind
19:03 HdkR: FEX has a prebuilt 32-byte binary file that's used during the build process that makes package maintainers pissy :D
19:05 HdkR: We also have the entire GCC test suite precompiled in a submodule of the tree, but neeh
19:19 rpavlik: some of us debian maintainers are quite reasonable...
19:20 rpavlik: but broadly, it's that anything that is not obviously clearly-licensed source code in the original, preferable-to-modify format, get extra scrutiny from a licensing POV.
19:22 rpavlik: Shipping a prebuilt 32-bit binary without sources terrifies me, yes, because there are presumably sources that were used to make it, and I don't have them to be able to verify that we have the right to use that/distribute that/etc, and I can't fix any bugs, port it to another platform, etc.
19:23 rpavlik: (But, it's very easy - if annoying - to exclude files from a debian source tarball. I do it all the time. As long as it's reasonably possible to rebuild from the preferred-modification-format source...)
19:24 rpavlik: Now, people complaining that you only provided the troff manpage instead of the MD they gave to pandoc? Eh. That's splitting hairs, what if you actually modify the troff file after that conversion and just used it as a first step?
19:25 HdkR: Oh, that's a good question actually. FEX fully generates a man page with cmake. I wonder if that's annoying?
19:25 rpavlik: The OpenXR SDK includes some shaders pre-compiled to spv, but the build system will just build them if the tools are available
19:25 rpavlik: HdkR: nah that sounds fine to me
19:25 HdkR: Nice
19:25 elibrokeit: rpavlik: no, I'm talking about shipping the .me and the .1 together in the tarball and having the build system skip producing a pandoc rule if the .1 is present and just directly installing it
19:25 rpavlik: sometimes I'll feel fancy and use pandoc in the packaging to turn markdown docs into HTML to install, or i'll use click-man to auto generate one
19:25 elibrokeit: *shipping the .md and the .1
19:26 rpavlik: elibrokeit that sounds perfectly reasonable
19:26 rpavlik: that's exactly what I'm doing with the shaders in hello xr
19:26 karolherbst: rpavlik: oh yeah.. in this case here it's just some OpenCL files compile to SPIR-V. Currently prototyping here: https://gitlab.freedesktop.org/karolherbst/mesa-libclc
19:26 karolherbst: and it just needs clang-22 to build
19:26 rpavlik: I don't remember offhand who the maintainers for the mesa packages are though. They might be pickier than me. I'm just a DM despite my decades of debian packaging
19:27 karolherbst: right.. I just don't want to run into the issue that if I decide to use it in e.g. 26.1 in a stable fix that people would decide to pick the old upstream impl, though in that case it's not a regression, might just not ship fixes for OpenCL builtins
19:27 rpavlik: I think they hang out in #debian-x iirc
19:28 rpavlik: karolherbst so like, if you didn't update the prebuilt?
19:28 karolherbst: I want to move away from llvms version, because release schedule and other changes make it difficult to use reliably
19:28 karolherbst: and just have our own fork + fixes/changes
19:28 karolherbst: and it's just spirv files
19:29 rpavlik: ah alright, yes, I see now.
19:29 elibrokeit: that does remind me, I still have a vague intent of adding a `dist: true` kind of kwarg to meson custom targets
19:29 karolherbst: so the spirv files are for those that don't have easy access to clang-22, due to LTS reasons or whatever
19:29 rpavlik: realistically, it comes down to the individual maintainers in that case. I personally do not see anything wrong with using a prebuilt spv in a source tree, if the source is there along with the way to rebuild them, and it's just a pain to do so
19:30 elibrokeit: that would result in `meson dist` building that custom target and including the output in dist tarballs so that when building from a dist tarball, `meson setup` can detect the pre-built and transparently use it
19:30 karolherbst: right, that's my hope
19:30 karolherbst: I just don't want to drop a "yeah.. you need clang-22 on a stable mesa update now" on distros
19:30 rpavlik: that sounds fine to me, basically the same thing as OpenXR-SDK except we check ours in to the tree instead of doing anything on make dist
19:32 karolherbst: the other issue is that the SPIRV-LLVM-translator doesn't do releases and distros are kinda slow in updated in on their own.. and that could also lead to bugs, but that's another problem and also solved by the SPIR-V backend in LLVM, so... yeah...
19:32 rpavlik: looks like Timo Aaltonen, Dylan Aïssi, and smcv are the main people on the package
19:32 karolherbst: (which is also used to compile libclc to SPIR-V)
19:32 karolherbst: yeah tjaalton is here
19:32 rpavlik: i know two of those 3, at least one of the 3 has a high opinion of my packaging skills ;)
19:32 rpavlik: ugh upstreams without releases
19:33 karolherbst: yeah...
19:33 karolherbst: not blaming distros on this, it's just annoying becasue that does sometimes lead to unfixed bugs
19:33 rpavlik: annoying but work-around-able
19:33 rpavlik: just a big pain
19:33 karolherbst: yeah...
19:33 karolherbst: we just had it recently...
19:34 karolherbst: I suspect what robclark was seeing here is caused by a distro (debian here) not updating it: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/8408#note_3562250
19:35 karolherbst: _But_ that's like fixable easily and not a "project rules disallow us from rebuilding it" situation which I want to avoid
19:41 elibrokeit: didn't spirv-llvm-translator release a new version like two weeks ago containing 22.* backports
19:41 rpavlik: so when I feel really pedantic I do sometimes try to migrate to not use prebuilts in a package. but I don't believe there is a rule. If there is a rule I've been breaking it
19:41 karolherbst: there are no tags
19:42 karolherbst: phh wait
19:42 karolherbst: there are?
19:42 karolherbst: ohh seems like since 21 they do that way more often
19:42 karolherbst: anyway that seems new
19:43 elibrokeit: gentoo's 22.1.4 package, added on 2026-07-05, builds from a tag :D
19:43 karolherbst: okay good to know that that has changed
19:44 elibrokeit: you can also get 24.0.0_pre20260714 but that's "unkeyworded" so Gentoo won't install it by default.
19:44 karolherbst: guess just need to ping distros to update more aggressively then
19:45 rpavlik: "should" not use vendored libraries - https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies - ran out of time to find the part about prebuilts
19:46 karolherbst: okay, but ours is patched for good reasons.. not sure if debian could apply those patches to the libclc build..
19:46 karolherbst: but like...
19:47 karolherbst: a new version also can add regressions, so...
20:04 DemiMarie: Drop the option to build with a system one? If it isn't going to work, there is no point in supporting it.
20:09 eric_engestrom: karolherbst: I'm not sure I understand your question; if you're asking whether having this only in release branches is ok, I think would have to say no, because devs pretty much only test main, not releases, so it would basically make devs' mesa and users' mesa different things, which is a recipe for disaster
20:10 karolherbst: eric_engestrom: I mean doing it as a bug fix on release branches while also doing it on main
20:10 elibrokeit: the question is whether it's okay to backport a bug fix if the bug fix involves adding a new build dependency
20:11 eric_engestrom: karolherbst: ah ok, then yes if it's a commit on main that is backported during the -rc period, I'm ok with that
20:12 eric_engestrom: although if it would've been after the last -rc, I would add another -rc after that before making it .0 final
20:12 eric_engestrom: *after the last _planned_ -rc
20:13 elibrokeit: can it be backported *even further*, to existing stable releases that are packaged in Debian stable, is the question
20:18 karolherbst: eric_engestrom: I also want to apply it to 26.1 :')
20:19 karolherbst: but I guess we could make it 26.2 only
20:19 robclark: side note: Maybe getting a working clc spv in mesa-ci would be a nice first step :-)
20:19 karolherbst: robclark: yeah but same solution really
20:20 robclark: yeah, if it was part of mesa build it would solve both
20:20 eric_engestrom: karolherbst: that's not something we normally do, and I'm uncomfortable making an exception to that rule
20:20 karolherbst: right...
20:20 eric_engestrom: (which now that I think about it, might not be written down, I should probably do that)
20:20 karolherbst: could maybe make it optional then?
20:21 karolherbst: I do want it to be more or less drop-in with libclc, just different paths, but that's all baked in at compile time in mesa
20:21 eric_engestrom: what's the failure mode? completely broken, or some games might have a visual glitch?
20:21 eric_engestrom: maybe just a fallback might be ok
20:21 karolherbst: so on 26.1 we could say, if you got the mesa-libclc version, great, if not well.. you get bugs
20:22 karolherbst: eric_engestrom: OpenCL builtins having wrong results or some OpenCL code not compiling using certain builtins (e.g. cos/sin on libclc-22)
20:22 karolherbst: like there has been a fix for tgamma that is libclc-23 only
20:22 eric_engestrom: I see
20:22 karolherbst: and I kinda want to ship with one that passes all the CTS tests
20:22 eric_engestrom: so yeah, what about a fallback? look for mesa-libclc, if you don't find it use libclc
20:22 eric_engestrom: for 26.1 I mean
20:22 karolherbst: yeah that's what I just suggested
20:23 eric_engestrom: for 26.2+ just make it depend on mesa-libclc
20:23 karolherbst: okay
20:23 karolherbst: yeah we can go with that
20:23 karolherbst: or maybe we should do the fallback also on main + 26.2 and give distros some time to package it...
20:23 karolherbst: or maybe it's fine for 26.2...
20:24 karolherbst: I suspect some will miss it if it's not a compile error..
20:24 eric_engestrom: sure, but also if you make it optional there's a good chance it will just be ignored
20:24 karolherbst: right..
20:24 karolherbst: yeah anyway, making it optional for 26.1 is fine
20:24 eric_engestrom: I'd say make it mandatory for main
20:24 elibrokeit: you can make it a build option and if you don't explicitly set the build option "to use deprecated libclc" then it errors out
20:24 eric_engestrom: 26.2 is up to you
20:24 karolherbst: not that it's like worse than the status quo unless distros update their llvm major version which _none_ does
20:25 eric_engestrom: elibrokeit: true
20:25 karolherbst: but libclc-22 is kinda broken and upstream is already EoL :')
20:25 elibrokeit: hey, Gentoo updates the llvm major version as fast as upstream llvm releases it :P
20:25 karolherbst: not sure if anybody ships mesa 26.1 + llvm-22
20:26 elibrokeit: now admittedly that does not help if llvm declares one version EOL before the next version is even released
20:26 eric_engestrom: also, I see your MR; split it into two commits, one for adding `mesa-libclc` before `libclc`, and then a second commit that removes `libclc`, that way you can add the backport tag you decide for each commit (26.1 for the first one, 26.2 or nothing for the second one)
20:26 karolherbst: eric_engestrom: yeah good idea
20:26 karolherbst: I should also create some CI pipeline for the fork.. that's going to be fun
20:28 eric_engestrom: to compile llvm, or to install a prebuilt one and compile the spirv files?
20:29 karolherbst: the latter
20:29 karolherbst: it requires clang-22 and it heavily makes use of clang specific builtins...
20:29 karolherbst: so I really want build testing there
20:30 karolherbst: and then maybe a release pipeline that provides the spirv files
20:30 elibrokeit: karolherbst: Gentoo ships mesa 26.1 + llvm 22
20:31 karolherbst: oh no
20:31 elibrokeit: in fact Gentoo builds 26.0 against llvm 22 also :)
20:31 karolherbst: it really wants to use the fork then...
20:31 karolherbst: but also gentoo is a bit special there
20:31 elibrokeit: (users can actually use whatever version of llvm they want, even llvm 18, but the default is "the latest one tested to work" and llvm 22 has been tested and enabled for mesa)
20:32 robclark: pls include scary warning msg if falling back to system clc ;-)
20:32 karolherbst: yeah..
20:32 elibrokeit: <elibrokeit> you can make it a build option and if you don't explicitly set the build option "to use deprecated libclc" then it errors out
20:32 elibrokeit: you can do better than a scary warning!
20:32 karolherbst: I was also considering failing `CL_DEVICE_LATEST_CONFORMANCE_VERSION_PASSED` when the system one is used 🙃
20:33 karolherbst: but not sure anybody cares about that
20:41 eric_engestrom: yeah I don't know the CL ecosystem but this feels like the sort of things exactly two apps would even look at: `clinfo`, and the cts
20:42 karolherbst: heh
20:43 karolherbst: anyway the project is really just a bunch of CL files that will be compiled to SPIR-V files (for 64 and 32 bit) and it uses clang and the spirv-llvm-translator (or the llvm spirv backend) to do that... so in theory it shouldn't be difficult and I don't really plan to make it its own project. I'll just create branches that cp libclc/ from LLVM and
20:43 karolherbst: add a bunch of changes to make it all work out (which is what other vendors are doing anyway)