07:51 MrCooper: DavidHeidelberg[m]: re https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23629 , so a rule with both changes: and exists: for the same file will match only if that file is created in the MR?
08:01 MrCooper: DavidHeidelberg[m]: even so though, the pipeline of an MR which touches only .ci-farms/$farm and nothing else will have all test jobs for that farm, but not their dependency jobs, will it?
08:02 zzag: Do you know if vgem used to have a bug where drmPrimeFDToHandle() could fail with "Permission denied" in older kernels (5.4.0-ish)?
08:36 dolphin: agd5f: I think on wifi side such calibration data resides under firmware
10:02 DavidHeidelberg[m]: MrCooper: the goal is to match, when file was changed and exist (which should imply creation)
10:54 Venemo: does someone here understand how return values are supposed to work in NIR?
10:54 Venemo: nir_jump_return talks about some deref passed from the caller, but what if the shader doesn't have that
13:53 jenatali: Venemo: That's how return values work, I don't think nir models them as a value passed to the return instruction, but as a local variable in the caller that the callee writes to via a deref arg passed in
14:20 Venemo: jenatali: what if there is no caller
14:20 jenatali: Then who are you returning a value to?
14:34 gfxstrand: Venemo: Yeah, we don't model return values in any real sense. Return is just control-flow. Everything is void.
14:35 gfxstrand: That was a deliberate choice because if we did model return values, they would be an SSA def but that's not sufficient for SPIR-V or GLSL's needs anyway because they need you to be able to return an array of structs of random crap.
14:36 gfxstrand: If it were clear that modeling return values would let us effectively optimize some neat cases, then maybe, but so far I don't see that it would.
14:37 jenatali: Yeah DXIL does both, a call of something that *can* be an SSA value will be (when not inlining, i.e. raytracing), but structs are caller-allocated variables and passed by pointer
14:37 jenatali: Just like the C++ ABI because LLVM
14:45 gfxstrand: Well, LLVM SSA values can be structs of arrays of crap, though.
14:45 gfxstrand: NIR is more limited there.
14:46 gfxstrand: Also, as far as NIR goes, not dealing with that makes everyone's life so far simpler. It makes spirv_to_nir simpler because it doesn't have to "optimize" return values based on type and it makes nir_inline_functions simpler because it doesn't have to think about return values.
14:47 gfxstrand: We also don't have to figure out what to do with them in nir_lower_returns
14:47 gfxstrand: And those are all the things that touch functions, really.
15:02 jenatali: Yeah, so far anyway. Until karolherbst has his way and functions stick around to the backend
15:03 karolherbst: I mean.. treating the return value as a pointer to storage should be fine...
15:03 karolherbst: backends can optimize that to registers if they feel like it
15:04 karolherbst: function_temp is already stack memory and gets optimized to ssa values if possible
15:24 Venemo: jenatali, gfxstrand I want to have a return value from the main function somehow
15:25 alyssa: Venemo: we're going to need a lot more info than that :-D
15:27 Venemo: basically I want to model the ac return values in nir somehow
15:28 Venemo: in radeonsi's llvm backend they are modeled as a return value from the main function, so I was hoping I coud do something similar
15:29 jenatali: "ac"?
15:31 Venemo: we have ac_shader_args for modeling the initial register state of waves
15:31 Venemo: it has shader args that represent input registers, and it also has returns that represent output registers
15:32 Venemo: radv/aco hasn't needed to use these returns yet, but radeonsi/aco will need them, and potentially radv's ESO implementation may need them also
15:32 jenatali: Ah, I see
15:33 jenatali: Can you add derefs as function args for the outputs?
15:33 Venemo: uhh, I don't know, I really hate dealing with derefs
15:34 Venemo: we already have load_scalar_arg_amd / load_vector_arg_amd maybe the best way to go about it would be to add corresponding store intrinsics
15:35 jenatali: Seems reasonable
15:35 Venemo: thanks
15:37 alyssa: Venemo: for ESO on AGX, I was planning to add store_arg_agx intrinsics (or something like that)
15:37 alyssa: there are some slightly tricky details around SSA-based RA
15:37 alyssa: but I think ACO already has all that code for epilogs
15:37 Venemo: yeah, kind of
15:38 Venemo: but they are currently very radv specific
15:38 jenatali: Am I supposed to know what ESO stands for?
15:38 Venemo: ESO = VK_EXT_shader_object
15:38 jenatali: Ah
15:38 Venemo: sorry I thought this is how everyone around here was calling it
15:39 jenatali: It makes sense, and I'd probably seen it before, I just haven't seen it in a few weeks
15:40 alyssa: oh I still need to record that song about ESO
15:40 alyssa: i already have my mic set up from earlier--
15:40 alyssa: wait no fixing discard() regressions is higher priority nvm
15:42 jenatali: I usually see that acronym talking about Elder Scrolls Online so I was confused for a bit lol
15:44 karolherbst: dcbaker: you think there is a way to force bindgen to use the same LLVM version than clang is using? I think this is a pattern coming up quite a lot
15:47 dcbaker: karolherbst: yes. We should be able to force that. I’ve thought about that before and just never wrote the code
15:47 karolherbst: there is also `bindgen --version --verbose`
15:47 karolherbst: not sure if it prints the version of the thing it compiled against or runs against
15:48 karolherbst: but it's all kinda weird
17:54 karolherbst: MrCooper: I found out today, that the nouveau overloaded virtual warning can also be disabled via -Woverloaded-virtual=1
17:54 karolherbst: maybe we should use that instead and I kinda plan on adding it in some non annoying way
17:55 karolherbst: it's annoying that at `Wall` it's using the 2nd level
17:55 jenatali: Can I get a quick review on a compiler warning fix? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23634
17:55 orbea: i think that is intentional for -Wall...
17:56 karolherbst: yeah... but easy to workaround if you want to keep the 1st level
17:56 gfxstrand: jenatali: rb
17:56 karolherbst: s/easy/annoying
17:56 jenatali: TY
18:22 italove: can someone versed on the mesa foz cache take a look at this https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23655 and say if it makes sense that the payload size is ~4GB in some cases?
18:28 cmarcelo: kusma: trying to figure out what restrictions we have here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23278#note_1956334 jesse also mentioned you had link to a video that explain how things get bad when linking C++ runtime library.
18:35 kusma: <cmarcelo> "kusma: trying to figure out what..." <- libc++ doesn't have a stable ABI, things go horribly wrong when two different DSOs link to two different versions of libc++, which happens if mesa and for instance a game links to slightly different versions of libc++. See the libcapsule presentation for more details.
18:38 cmarcelo: kusma: thanks. how do we prevent issues to happen for ACO, and for whatever we have that uses LLVM (which I think also uses C++ standard library more widely)?
18:39 kusma: cmarcelo: ACO is afaik broken in this sense. I guess we just haven't seen any games where it leads to issues yet, but I expect we will at some point.
18:39 cmarcelo: kusma: should we be static linking libstdc++ instead?
18:41 kusma: No, that will make distros hate us. We shouldn't depend on libc++ IMO. There are some other possible ways of working around it (again, see the libcapsule video), but they're not around for every platform we support.
18:42 cmarcelo: will watch the video, thanks :)
18:42 kusma: Np
18:44 gfxstrand: C forever!
18:44 gfxstrand: Until we switch to rust. :-P
18:50 bylaws: What's the problem with multiple libc++ versions in the same process?
18:51 bylaws: This very much happens all the time in android so curious what's different in linux
18:51 DrNick: C++ puts the symbols in different ELF namespaces, so there aren't conflicts in that regard, but it will cause problems if you have e.g. C++ container types in your ABI; also WIndows ports did ill-advised things like partially replace operator new and delete, and then that burst into flames when new versions of the C++ runtime introduced additional operators
18:52 jenatali: Android has linker namespaces. The glibc linker doesn't
18:52 DrNick: e.g. Battleblock Theater won't run anymore without a binary patch, and Team Fortress 2 was broken for a bit
18:53 DrNick: glibc has refused to implement the feature that Apple calls two-level symbol lookup, Sun called direct binding, and Microsoft didn't bother to name because it is the obviously correct way to do it and they never screwed up their DLL interface in the first place
18:54 bylaws: Oh so the issue is games not static linking libcpp and shipping their own?
18:54 bylaws: Fair enough
18:54 DrNick: that too
18:54 jenatali: Doesn't matter where it comes from, but two versions in the same process will both try to provide the same symbols, even though their implementations might be different
18:55 jenatali: And since neither the app nor Mesa are explicitly loading their symbols from a particular version of the library, one or the other can start calling into functions expecting different struct layouts (or other similar problems)
18:55 cmarcelo: jenatali: if both dynamically linked you mean? if either mesa or game static link, there's no problem right?
18:55 jenatali: As long as the symbols that are statically linked are also hidden, then sure that's fine
18:55 jenatali: Hidden and non-relocatable
18:57 karolherbst: why does the glibc linker refuse to implement this though?
18:57 karolherbst: especially as this is such a painful problem
18:58 jenatali: Dunno. I was super surprised when I learned that ELF did symbol lookups this way, and even more surprised when I learned that Android didn't have this problem
18:59 jenatali: But IMO Android's system is still super fragile since it depends on the caller return address to figure out which namespace to use
18:59 bylaws: It's cute, they use it for enforcing what libraries vendors use in their blobs
19:00 jenatali: Yeah. I'm well aware
19:00 airlied: glibc has the dlmopen but it doesn't seem to either work or be what people need
19:01 bylaws: But the feature is also lovely for hooking symbols without editing any code or doing weird linker hacks, I use it to replace/hook android vulkan drivers
19:03 pac85: Many old linux games builds from icculus.org have libstdc++ linked statically, however some symbols are still exposed so those build explode as soon as mesa is loaded. After fixing that I got a build from 2003 running (it even runs natively on wayland through sdl1on2)
19:06 cmarcelo: kusma or anyone more versed with distro building: the restriction from the distros here is that they don't want mesa to static link libstdc++ because would imply updating libstdc++ would need to produce a new mesa package? or is there some other issue at play?
19:08 psykose: it adds a bunch of size that doesn't have to be added because the libstdc++.so is already there
19:09 milek7_: couldn't symbol versioning be abused for scoped symbol resolution?
19:09 DrNick: that's how libstdc++ works now
19:10 DrNick: the problems crop up when the app ships a stale copy of libstdc++ that gets loaded before the newer system copy
19:10 DrNick: or when people make the mistake of putting STL containers or other types in their ABIs
19:10 eukara: pac85: what's the proper 'fix' for this? been unable to run one of my fav games for a while because of this
19:11 DrNick: or when the application partially replaces malloc/new, and then the newer C++ code the app loads allocates using the app's allocator and then attempts to free using the libstdc++ allocator
19:12 karolherbst: eukara: normally you just remove the libstdc++ the game ships and hope it works
19:12 DrNick: if the application was built against an older version of libstdc++ and loads libraries built against newer versions of libstdc++, and none of the aforementioned shenanigans have occurred, it'll work fine
19:14 milek7_: well, libc++ types in ABIs would blow up on windows too?
19:14 DrNick: yes
19:14 milek7_: and libc allocators might be different, so existence of CoTaskMemAlloc and others
19:14 DrNick: the history of Microsoft can be viewed through a lens of trying to make C++ useful in an ABI
19:14 DrNick: which is how you get COM and WinRT and so on
19:15 cmarcelo: mesa doesn't use C++ as part of API/ABI, so we want to prevent mesa code from loading the extenral (i mean from the game/app) libstdc++ code, is that a right?
19:16 jenatali: We need to prevent Mesa from calling into C++ runtime code that comes from a different version than was linked against, yeah
19:17 jenatali: And ideally also the other way around, don't pollute the global linker namespace with C++ runtime functions that can conflict with what the app linked against
19:17 pac85: eukara: I'm sure there is a better way but I just opened the binaries and so files in vim and renames the symbols (replacing characters without changing the length of course). If there are a lot of conflicting symbols that's not viable. A friend of mine wrote a python script to do this so if you want I can see if I can find it.
19:17 DrNick: the C++ symbols are versioned, so Mesa won't call into the old version, what happens instead is radeonsi_drv.so fails to load because the newer C++ version isn't present and you get software rendering
19:18 mattst88: tbh, I'd worry about solving this problem if it actually happens
19:19 airlied: like this https://airlied.blogspot.com/2023/04/fedora-38-llvm-vs-team-fortress-2-tf2.html ?
19:22 mattst88: oh :(
19:24 HdkR: I'm also exposing C++ over my library ABI. I need to fix that at some point. It's spooky.
19:25 DrNick: you can expose C++ in your library ABI, but you have to reinvent COM to do it
19:25 jenatali: I don't see how COM is related to C++ ABIs
19:25 DrNick: basic C++ features like constructors and destructors can't be used in your ABI
19:26 HdkR: Nah, I'm just going to shift everything over to C interfaces to be safe :)
19:26 DrNick: because they inline object size and layout
19:28 DemiMarie: What is the reason for Mesa dynamically linking to libc++ and LLVM?
19:28 jenatali: *on Linux
19:28 jenatali: On Windows we statically link it all in
19:28 karolherbst: $distributions
19:29 DemiMarie: Could one option be to run the LLVM stuff in a dedicated subprocess?
19:29 milek7_: microsoft have weird history with libc++ stability
19:29 milek7_: like, at beginning they had single abi-compatible msvcrt.dll, then they changed to separate dll for each VS verison, and now they again have stable abi since 2015
19:29 DemiMarie: karolherbst: drop support for dynamic linking?
19:30 karolherbst: I mean... sure, why not, but distributions will come around with torches
19:30 DemiMarie: What about dlmopen()?
19:30 milek7_: and eg. sleep_for is broken for years because they keep old abi
19:31 DemiMarie: HdkR: my solution to this kind of problem is to explicitly state that the ABI is not stable and will never be stable, and that users of the library need to be rebuilt every time the library is rebuilt.
19:31 DemiMarie: Distributions need to get better at cascading rebuilds anyway
19:31 karolherbst: DemiMarie: tell that to game publisher
19:32 HdkR: DemiMarie: My plan is to be stable at some point for my little slice of the world at least
19:32 DemiMarie: karolherbst: presumably HdkR isn’t shipping a C++ ABI for use in Mesa.
19:33 DemiMarie: HdkR: what slice is that?
19:33 karolherbst: DemiMarie: the core issue is rather something like this: https://airlied.blogspot.com/2023/04/fedora-38-llvm-vs-team-fortress-2-tf2.html
19:33 DemiMarie: to me the ideal solution is to have the symbol names include an ABI hash (as Rust does), so that you get a link error rather than a runtime crash
19:33 HdkR: DemiMarie: Emulated games with GL/Vulkan punched through to native libraries
19:34 karolherbst: DemiMarie: the problem isn't binaries being build incorrectly :)
19:34 pac85: If stdc++ is used by drivers and not by libgl couldn't mesa use RTLD_DEEPBIND?
19:34 DemiMarie: HdkR: report this as a Fedora bug
19:35 DemiMarie: pac85: the answer might be `dlmopen()` but other options include having Mesa ship its own dynamic linker (I kid you not!) or just making static linking compulsory.
19:36 mattst88: I don't think this is helping
19:36 DemiMarie: mattst88: why?
19:37 mattst88: mesa isn't going to ship its own dynamic loader or invent something to run llvm in a separate process
19:37 mattst88: those are, tbh, rather absurd ideas
19:38 DemiMarie: In that case tell distros that they have to link Mesa statically against LLVM and libc++ or they get to keep both pieces when something breaks.
19:38 DrNick: nah, running LLVM out of process makes sense, especially when you're supporting 32-bit applications with limited address space, it's only an absurdity because Linux doesn't have a good RPC story
19:38 pac85: DemiMarie: hasn't gnu recently broken the symbol table format? I don't like the idea of shipping a dynamic linker.
19:38 DemiMarie: “Linux doesn't have a good RPC story” what do you mean?
19:39 DrNick: and complicated by the distro propensity to upgrade packages while they're in use, which opens you up to race conditions where a GL-using application is starting up and loads the old version of Mesa before the out-of-process compiler gets started and you end up with a version mismatch
19:40 jenatali: 😅
19:40 DemiMarie: `execve(/proc/self/fd/<memfd>)`
19:40 DemiMarie: yes, you can spawn a process without ever touching a file on disk
19:40 HdkR: execveat is the better use
19:41 DrNick: that would require you to make a hybird object that's both a library and an executable, which is doable (see glibc itself) but weird
19:42 HdkR: Also execve inside environments that might remove all your binaries breaks this :)
19:42 HdkR: Basically the world sucks and there's no "perfect" solution
19:43 DemiMarie: HdkR: that is why I suggested a memfd
19:43 DemiMarie: That said submitting patches to glibc is the best option.
19:44 psykose: glibc isn't the only libc in the universe
19:46 DrNick: we're talking about Linux though, not non-Linuxes like Android
19:46 heat_: *cough cough* musl *cough cough*
19:46 DrNick: or non-Linuxes like Alpine
19:47 pac85: Why is llvm a problem? I mean games don't ship their llvm so why would it be problematic?
19:47 jenatali: Are there other libcs besides glibc and musl that have this problem?
19:48 pac85: You mean the problem of not having namespaces symbols?
19:48 jenatali: Yeah
19:49 DrNick: presumably every single ELF implementation on all the no-longer-relevant operating systems that didn't copy Sun's direct bind symbol lookup extension
19:49 jenatali: Heh, guess I should've added "relevant" to my question
19:50 pac85: jenatali: I think the BSDs do the same thing but I'm not 100% sure
19:50 DemiMarie: jenatali: maybe at least musl can be persuaded to take a patch?
19:50 DrNick: that assumes the BSDs are relevant
19:50 DemiMarie: DrNick: They are
19:50 DemiMarie: Maybe not for proprietary games but they are for Mesa in general
19:51 psykose: alpine is a linux distro like others
19:51 psykose: glibc = linux is a hilarious way to think about it i guess
19:51 karolherbst: BSD is relevant for Mesa? I doubt that
19:52 pac85: I think as far as games go linux is the only one with that problem. I wonder if games could fix it by mangling their symbols
19:52 karolherbst: well they can't
19:52 pac85: Why?
19:52 karolherbst: as publishers are not republishing games because of trivialiaities like this
19:52 pac85: I mean sure
19:52 karolherbst: some don't even have linux teams anymore, so the binary stays as is forever
19:53 DrNick: musl is very much a CADT "throw everything out and start over" product that isn't worth seriously considering
19:53 pac85: i meant as a game developer who wants to ship a proper game
19:53 gfxstrand: dcbaker: How do we assert particular rust versions in meson?
19:53 pac85: Would that be an option?
19:53 karolherbst: it doesn't fix the issue with broken binaries
19:54 pac85: Yeah I understand that.
19:55 dcbaker: gfxstrand: something like `rc = meson.get_compiler('rust')\nif rust.version().version_compare('!= 1.5')\nerror('Requires Rust 1.5')\nendf`
19:55 dcbaker: and I spelled rc two different ways in 1 line... sigh
19:55 pac85: But is symbol resolution the only thing preventing multiple versions of the same library to live in the same process?
19:56 psykose: DrNick: that should be officially put in a readme somewhere for mesa then, i.e. "only glibc is supported"
19:56 psykose: you should propose such a change
19:56 mattst88: pac85: to answer your question "Why is llvm a problem?" -- the problem is that it links (potentially dynamically) with libstdc++, which might be newer than the old one a game bundles
19:57 mattst88: so since your OpenGL driver loads llvm, libstdc++ is in your process, and then when the game tries to load its own... things break
19:58 pac85: mattst88: Oh I see, thank you. Also libstc++ is loaded directly by many drivers afaik so how does putting llvn in a differenr process solve it?
19:58 mattst88: pac85: that wasn't my idea, but I don't think it would
19:59 DemiMarie: pac85: in that case Mesa should make static linking of libc++ compulsory (as in if you try to link dynamically, you get a build error explaining why what you are trying to do is a bad idea)
19:59 DrNick: if the application uses it's stale version of libstdc++ via RPATH, then the out -of-process compiler won't have that RPATH; if it uses it via LD_LIBRARY_PATH it'll still break
20:00 mattst88: I look forward to y'all's patches to run the shader compilers in a separate process
20:00 DemiMarie: DrNick: not if the out-of-process compiler is statically linked and starts with an empty environment
20:00 gfxstrand: dcbaker: Thanks! That works modulo the typos. :)
20:00 DemiMarie: mattst88: then static linking is the only good solution I can think of.
20:00 pac85: DemiMarie: feels a bit extreme. I wonder if a tool could be made that implements a custom dynamic linker for the game, this way those games could be loaded without changing anything in the system
20:00 karolherbst: ever implemented a custom dynamic linker?
20:01 DemiMarie: pac85: maybe? though honestly trying to ship a game for desktop Linux except via Flatpak is probably a bad idea
20:01 dcbaker: gfxstrand: I've learned the value of the phrase "something like" due to all the typos :)
20:01 gfxstrand: dcbaker: :D
20:01 gfxstrand: Wise
20:01 karolherbst: reminds me that I might want to check for the rustc version as well
20:01 DemiMarie: karolherbst: no, but GHC (Glasgow Haskell Compiler) wrote their own linker for `.a` files, which I imagine is even harder
20:01 karolherbst: why would it be?
20:01 pac85: DemiMarie: flarpak is probably a bad idea for games as I discussed. Old games would end up depemding on old euntimes that wouldn't be able to load recent mesa for recenr hw
20:01 karolherbst: it's just merging some things
20:01 DrNick: no that's easier, static linking is extremely simple compared to dynamic linking
20:01 DemiMarie: That said I still think the best solution is to fix glibc
20:02 DrNick: glibc is under new management, you might be able to convince them
20:02 karolherbst: :D
20:02 pac85: karolherbst: nope. I suppose you are suggesting that it is theoretically possible but not pratical?
20:02 karolherbst: something like that
20:02 DemiMarie: What about bundling the OpenBSD dynamic linker?
20:02 DemiMarie: Or a fork of it
20:02 karolherbst: but I think nobody wants to do it
20:03 karolherbst: uhhh
20:03 karolherbst: no
20:03 mattst88: lol
20:03 gfxstrand: I *think* NAK is going to stick to 1.17.0
20:03 pac85: I'm not suggestinf bundling anything btw
20:03 mattst88: this channel...
20:03 DrNick: point out that applications replacing the C++ memory allocator and then libstdc++ breaking ABI by introducing new allocator functions that the app couldn't implement because time travel is impossible is a serious problem
20:03 karolherbst: gfxstrand: fair
20:03 pac85: My idea was a tool external to both the gamr and mesa
20:03 karolherbst: gfxstrand: distributions will hate you though
20:03 gfxstrand: We'll see if something really juicy lands in the next couple releases but I think locking at 1.17.0 is probably the best we can do.
20:03 mattst88: #dri-devel-pontificating
20:03 gfxstrand: karolherbst: If distros are shipping NAK this year, I'm going to hate them. :-P
20:03 karolherbst: :D
20:03 karolherbst: fair enough
20:04 karolherbst: yeah.. the next FireFox ESR probably needs something newer than 1.70 so that should be fine :D
20:04 dcbaker: gfxstrand: btw, Did Xavier ever message you? He's been doing a bunch of Meson + cargo work
20:04 DemiMarie: mattst88: my understanding is that Mesa is such a large project that it could bundle an entire dynamic linker and not be significantly larger
20:04 DemiMarie: In fact I have often wished that the kernel drivers were part of Mesa
20:04 gfxstrand: dcbaker: I've chatted with him a little bit but not much.
20:04 gfxstrand: dcbaker: I thought he wasn't a fan of the meson cargo stuff ;-)
20:05 DemiMarie: As someone who is concerned about supply chain attacks: please use as little from crates.io as possible
20:05 karolherbst: DemiMarie: nobody wants to though
20:05 karolherbst: same as nobody wants to ditch libclang use by writing our own C frontend
20:05 dcbaker: One of the other gstreamer devs started working on it with me and convinced him it was worthwhile
20:06 karolherbst: DemiMarie: probably serde and syn
20:06 dcbaker: Demi: the plan we have (gstreamer devs and I) is that we'll have support for vendored dist tarballs
20:06 pac85: DemiMarie: how so you suggest to fetch crates?
20:07 gfxstrand: There's a few crates that are pretty much necessary if you want proc macros (which we do): syn, quote, and proc-macro2
20:07 dcbaker: but also we'll likely by default have pinned versioning anyway
20:07 DrNick: use Google's cargo vet list
20:08 gfxstrand: There's a handful of others that do something sufficiently obvious that I'm not too worried.
20:08 DemiMarie: yup, Google’s cargo vet list is a good idea
20:08 gfxstrand: But generally we plan to keep our list of crates small
20:08 karolherbst: we don't even use many native deps
20:08 gfxstrand: I'm happy to have a CI lint thing that checks against the Google list
20:08 karolherbst: yeah, same
20:21 DavidHeidelberg[m]: Demi: bundling more stuff sounds terrible :D I always loved how mesa over its own complexity most often builds fine everywhere
20:22 gfxstrand: Yeah, but we really don't like having to build everywhere. :-P
20:23 pac85: I mean after all it isn't really a mesa problem, it's a gnu linker problem
20:24 DavidHeidelberg[m]: gfxstrand: you'll have some serious explaining why Mesa won't run on my headless touster :P
21:40 Kayden: wow, some crazy ideas in the backlog
21:41 karolherbst: glad you like them
21:41 Kayden: I don't
21:42 Kayden: having worked on the GHC runtime internals, which include its own custom "Cmm" programming language and multi-phase-build to build a compiler for the custom language to compile the internals...I can say that I don't think mesa wants to emulate that level of accidental complexity, which is largely there because the maintainers can keep it going at that level of complexity
21:42 karolherbst: sounds fun
21:43 Kayden: there are just some restrictions that you get to have as being part of a library and you unfortunately don't get to invent your own linkers or tell everyone else how to use your project
21:45 karolherbst: yeah...
21:45 karolherbst: I mean... in the end it's just C++ being silly here and not specifying a proper ABI
21:58 cmarcelo: Kayden: Cmm = C "minus" "minus"?
21:58 cmarcelo: :-D
21:58 Kayden: one of at least 12 languages called that, with zero docs, yes
22:10 DrNick: imagine if C++ had the foresight to generate vtable and object layouts at runtime like Swift
22:29 jenatali: Looks like several CI runners are out to lunch
22:29 jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/909258
22:39 mattst88: it's funny, in Gentoo we provide some -bin packages for large applications like libreoffice and firefox
22:40 mattst88: but there's this one exception to that: shellcheck-bin
22:40 mattst88: 6 MiB on disk
22:40 mattst88: but in order to compile it yourself, you have to have like 40 Haskell packages including GHC, and the whole thing is a nightmare
22:46 daniels: jenatali: all the runners are online afaict
22:46 daniels: my god the signal:noise here tho
22:47 jenatali: Hm. Then why is that pipeline stuck?
23:39 daniels: jenatali: oh, I think I know why …
23:49 daniels: jenatali: think if you retry now it should be good
23:49 jenatali: Thanks!
23:51 daniels: np, sorry about that - that bug in GitLab runner scheduling should've been fixed, but apparently wasn't