11:02 zmike: eric_engestrom: did https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36576 get backported?
11:02 zmike: I'd like this to be in the release
11:02 zmike: or maybe you're doing one more pass with the backport scripts before
12:14 eric_engestrom: zmike: yes, its last two commits are in 25.2 :)
12:14 zmike: tremendous
12:14 eric_engestrom: I just did the final pass of backports
12:14 zmike: thanks
12:14 eric_engestrom: now in CI, and if it comes back green, that's 25.2.0 final
15:16 karolherbst: dcbaker: can anything be done about mesons overly aggressive caching of a compiler version? Like even on "setup --reconfigure" it doesn't want to requery the version of a compiler (which it normally should anyway, imho)
15:24 MrCooper: karolherbst: --wipe?
15:24 karolherbst: sure, but it's still annoying
15:25 karolherbst: I think it currently checks first if the binary itself changed, but what if you use a wrapper script? Anyway, would be nice if meson would be less trusting there
15:32 eric_engestrom: karolherbst: relevant: https://github.com/mesonbuild/meson/issues/10706
15:36 eric_engestrom: (the issue started about rustc but it applies to everything, and iirc the "it's a wrapper" case was not brought up, so it might be worth adding that in there)
15:36 karolherbst: not saying it should be checked on each build
15:37 karolherbst: just on reconfigure
15:39 karolherbst: but I don't buy the rustup argument, same would happen with ccache or any other wrapper around a compiler
15:44 karolherbst: anyway, not gonna engage in that upstream issue
15:46 eric_engestrom: fair
15:48 dcbaker: karolherbst: with rust?
15:49 karolherbst: well yeah, the issue is kinda that I want to reconfigure, but the meson fails, because it doesn't pick up the new version
15:49 karolherbst: e.g. because mesa requires a new version
15:50 karolherbst: not really rust specific tho
15:50 dcbaker: oh, yeah, with rust. yeah it's a rustup and we've asked for help from rustup with that and they've basically told me to eat shit, it's not their problem
15:50 karolherbst: if a project requires gcc-11 out of hte sudden and the cache is still 10.something you'd have the same issue
15:50 karolherbst: dcbaker: I mean... you have the same issue wiht literally every compiler wrapper
15:51 dcbaker: it doesn't happen for ccache actually
15:51 dcbaker: because ccache is either a symlink or detected as a separate binary
15:51 dcbaker: so ninja's stat'ing does the right thing
15:51 dcbaker: it's unique to a wrapper that proxies commands the way that rustup does, which is actually not very common
15:51 karolherbst: so meson has special handling for ccache?
15:52 dcbaker: yeah, and for scache
15:53 karolherbst: okay, so it works for ccache because meson knows how to handle ccache, but it doesn't work for rustup, because meson doesn't know how to handle rustup?
15:53 dcbaker: No, because rustup hides what it proxies
15:53 karolherbst: but then it would also not work for literally any other rnadom cc wrapper, would it?
15:54 karolherbst: like if I use a gcc_wrapper.sh, how would meson be able to detect that gccs version changes?
15:54 dcbaker: If gcc_wrapper.sh doesn't change it can't
15:54 karolherbst: okay, so it's not a rustup specific issue
15:55 dcbaker: it is in that no other compiler wrapper in common use works like rustup does
15:55 karolherbst: I don't see how that's relevant really, given there are compiler wrappers that don't work like the CC ones do?
15:56 dcbaker: Meson's special handling of ccache is "look for ccache, look for $CC, make a command of [ccache, $CC]"
15:56 karolherbst: sure
15:56 dcbaker: It's relevant in that if I write wrap_cc.sh I'm doing something weird, and I can reasonably expect that I get to keep the pieces.
15:57 karolherbst: why is that "weird"?
15:57 karolherbst: just because ccache does intercept --version?
15:57 karolherbst: or does something else to make it detectable?
15:58 mareko: having ccache in PATH works for me
15:58 karolherbst: like you use the implementation detail of specific projects to argue that every other project not doing it is "weird" or "hides" things
15:58 dcbaker: if you use the "symlink ccache as gcc" trick Meson will fail in the same way, but that trick is getting less common because CMake and Meson both handle things like ccache more elegantly than autoconf did. But CMake will fail in exactly the same way with the symlink trick that Meson does
16:00 dcbaker: This is one of those places that rust just fails to make a good argument for why they're changing the thing that everyone has done forever: stat the compiler binary to determine that you need to recompile
16:00 dcbaker: and Jussi is dead set that having to run rustc every time you invoke ninja is a non-starter, there needs to be a solution that doesn't involve that
16:00 karolherbst: so you rely on gcc being a symlink to ccache to detect ccache, but you could probably detect rustup by seeing rustc being in `~/.cargo/bin/`
16:01 karolherbst: but I thought stat on the compiler bin for ccache doesn't work?
16:01 karolherbst: like it only works because meson detects ccache and special handles it
16:01 dcbaker: So I have three imovable rocks here: rustup who says "we are breaking the convention and don't care, you figure it out", ninja who says "ninja is done and we're never going to add any more features ever" and Meson that says "requiring running rustc --version on every ninja invocation is a non-starter"
16:02 karolherbst: well I'm not asking meson to do that
16:03 karolherbst: I just think the arguments used in the debate aren't as strong as you imply they are, nor are there really fair. ccache has special handling, so it would be fair for rustup to get also special handling. Just need to figure out how to reliably detect it, no?
16:05 dcbaker: The special handling for ccache is that we detect ccache for you, and then know that the actual compiler is not ccache, it's the first argument to ccache, so stat that instead of ccache
16:06 dcbaker: The problem is we really need something from rustup that's not a command to run that we can stat
16:06 dcbaker: but that's really tricky (to be fair to them) with their per-folder configurations
16:07 karolherbst: so how I understand how rustup works is, that you have this "~/.rustup/settings.toml" file where you'd get the real binary from and an implicit directory structure to rely on
16:07 dcbaker: I mean, I'd love to solve this, but I've reached the point that standing between those three rocks there's no solution
16:07 karolherbst: right.. I do agree that having to parse their settings.toml file is a bit more work
16:07 dcbaker: But you can also have a ./.rustup/settings.toml, right?
16:07 karolherbst: (and potentially unreliable when the format changes)
16:08 karolherbst: dcbaker: within the directory?
16:08 karolherbst: *project directory
16:08 dcbaker: yeah
16:08 karolherbst: mhhh
16:08 karolherbst: never seen that one
16:08 karolherbst: but I could try if it works
16:09 karolherbst: mhh
16:09 karolherbst: doesn't seem to do anything
16:09 dcbaker: I guess not, not sure if that was an old way or I'm just misremebering?
16:09 dcbaker: It says in the docs it goes in ${RUSTUP_HOME}/settings.toml like you said
16:09 karolherbst: yeah
16:10 dcbaker: but it also says in the docs "this is all implementation details, use the cli"
16:10 karolherbst: though is $RUSTUP_HOME a thing?
16:10 karolherbst: maybe it defaults to ~ if not set
16:10 dcbaker: https://rust-lang.github.io/rustup/configuration.html
16:10 dcbaker: yeah
16:10 karolherbst: ohh yeah..
16:11 karolherbst: I mean.. a lot of things are implementation details, but things rely on it anyway
16:12 karolherbst: if something changes and we just get a supoptimal behavior out of it, so be it
16:13 karolherbst: so in theory meson (or rather ninja) would have to stat the settings.toml file and the actual rustc binary, right?
16:13 dcbaker: AFAICT the only robust solution is to always run rust --version and wipe if it changes. The next best solution would be to at configure time look for rustup and then add the rust --version check in that case (though you'd still have the corner of changing between rustup and non-rustup)
16:13 karolherbst: right.. rustc --version would be robust
16:14 karolherbst: though I do know that the argument of adding one exception may lead to adding more, but you can wrack your meson no-op build times by using static llvm quite massively already, so it's not like there aren't cases where your no-op situation is already horrible
16:14 dcbaker: stating the settings.toml would be a rough proxy I guess, you might get some spurious rebuilds...
16:15 dcbaker: s/rebuild/reconfigure
16:15 karolherbst: yeah whatever tho
16:15 karolherbst: though
16:15 karolherbst: couldn't you depend on rustc --version if the stat changes?
16:15 karolherbst: uhm.. run
16:16 karolherbst: and only rebuild if the version actually changes after that
16:16 mlankhorst: airlied: Hey, I'm working on some performance improvements when running with a dual card setup. One of the things that will help is the cgroup accounting, which allows us to configure memory in such a way that eviction won't happen. But what is needed to make it possible to implement memory/vram pinning for specific BO's?
16:16 dcbaker: karolherbst: that's the most straightforward way to handle it, but that's the "run rustc on every ninja invocation" that Jussi doesn't want
16:17 karolherbst: yeah, I get it
16:17 dcbaker: honestly, I hadn't thought of stating the settings.toml and that... would be a pretty good aproximation
16:17 karolherbst: like for me it would be fine if "reconfigure" would do it
16:17 dcbaker: there would still be corners... but it would work in like 99% of cases
16:17 karolherbst: but now I have to wipe the entire build directory, because meson refuses to configure with the old version
16:18 karolherbst: rustc --version is fast, I'm sure it won't impact reconfigure times at all
16:19 jannau: isn't stating settings.toml broken if the default toolchain is just stable / nightly?
16:19 karolherbst: detecting rustup and doing it all properly is certainly quite a lot of work, so if that needs time until that happens that's fine, just want at least something that's not _that_ annoying to deal with as what we have today
16:20 karolherbst: jannau: you'd state the rustc binary _and_ settings.toml
16:20 karolherbst: *stat
16:20 karolherbst: settings.toml because you might have to check a different rustc binary after it changes
16:22 jannau: how do you get the rustc binary? it's a hard link of rustup in the rustup case
16:23 karolherbst: ~/.rustup/toolchains/$whatever_is_in_settings.toml/bin/rustc
16:25 karolherbst: though the big question is what happens if any of those impl details of rustup change and meson falls apart
16:25 karolherbst: probably will have to check if those assumptions still hold and if not, fallback to non rustup handling and just have it not work great again
16:26 dcbaker: rustup which rustc gives you the actual binary
16:26 karolherbst: ohhh, didn't know that...
16:26 karolherbst: mhh
16:26 karolherbst: that also parses settings.toml...
16:26 dcbaker: honestly, checking for rustup and running using that to get the binary would help in a bunch of cases
16:26 karolherbst: yeah...
16:27 karolherbst: if rustup is in your path then you probably use it
16:27 dcbaker: at least that would fix the rustup udpate case...
16:27 karolherbst: well could always stat settings.toml and check if rustup which rustc changed its output
16:28 karolherbst: but not having to actually parse that file does simplify things
16:28 karolherbst: or know the internal directory structure
16:28 dcbaker: so I guess if you use rustup which rustc and stat the settings.toml you know if the binary has been updated, and you know if the binary has changed...
16:29 karolherbst: another check: compare "$(rustup which rustc) --version" with "rustc --version"
16:29 karolherbst: if that matches it's _very_ likely that rustup is used
16:31 karolherbst: I think in theory you could have a rustup in your PATH but not ~/.cargo/bin
16:31 karolherbst: some distros also ship rustup
16:31 jannau: if rustup is in path and is identical to rustc rustup is used
16:31 dcbaker: You can have that, since you can set $CARGO_HOME :)
16:32 karolherbst: jannau: ohh, yeah that would also work
16:32 karolherbst: but that kinda sounds like an implementation detail
16:33 dcbaker: on nixos rustc and rustup are both symlinks to something in /nix
16:33 karolherbst: I think the --version check would be more reliable therefore
16:33 dcbaker: just to be extra fun :)
16:33 dcbaker: I think so too, and doing that at configure time is fine
16:33 karolherbst: I meant to detect the use of rustup
16:33 karolherbst: but yeah
16:34 dcbaker: yeah, I think that might actually work. I need to get the "kill pipe_screen subclassing" patches out today, but I'll have a swing at getting those patches written
16:35 karolherbst: cool
16:38 karolherbst: the only annoying part I can see in all of this is, that it matters what your current working dir is for rustup to choose the rustc binary, but that's reasonable to expect developers to deal with themselves
16:41 dcbaker: I think the only way to hit that would be to have a per-directory override set, but then initialize meson from outside that directory? cd ~; meson setup /tmp/builddir source/mesa?
16:45 dcbaker: I added a short writeup of this to the issue that eric_engestrom linked. I'm about to go on sabbatical so I might not get to it before September, and that might be enough to get someone else motivated if I don't get it done :)
16:47 karolherbst: dcbaker: might want to mention that the default value of RUSTUP_HOME is HOME?
16:47 karolherbst: ehh
16:47 karolherbst: HOME/.rustup
16:48 karolherbst: also the link in there is broken
16:48 karolherbst: but yeah, looks good
16:54 karolherbst: I already drafted it, so if you are fine with it, could just send it as is
16:55 karolherbst: ehhh wrong channel 🙃
17:45 K900: Question for folks: as a distro, we've usually waited for the .1 release of a new Mesa branch to ship it out, but it feels like it's not really necessary anymore? How do folks from Mesa/other distros feel?
17:45 zmike: it varies by release
17:46 zmike: some are good
17:46 zmike: some are less good
17:50 HdkR: All the unittesting in the world can't catch all the bugs.
17:56 karolherbst: more users on .0 early will help fix more regressions for .1 but it's kinda your call on how regression free you want your distro to be
17:57 karolherbst: like if everybody would use .1 and not .0 then .1 would be kinda full with regressions probably
17:57 karolherbst: or rather.. the regressions would be fixed later
18:04 eric_engestrom: indeed, *someone* has to be the first, if everyone waits for someone else then it just delays everything without anyone being better off
18:21 K900: I think we can afford this then
18:21 K900: Now that we have a cheap out to downgrade
18:34 karolherbst: airlied: you do I need to ping to get the spirv translator updated in fedora 🙃
18:34 karolherbst: *who
18:35 karolherbst: might want to rebuild for fc42
18:36 karolherbst: need at least https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/3120 in
18:36 karolherbst: but maybe it should be rebuild on each llvm/clang update automatically
18:36 karolherbst: *rebuilt
18:37 karolherbst: (same for other distributions not doing it already)
18:38 karolherbst: not sure their release cycles align with llvm tho, but..
19:10 airlied: karolherbst: not sure anyone owns it really, I used to update it with mesa sometimes, I can add you or maybe send a PR and I can pull it
19:23 airlied: mlankhorst: not sure, I suppose pinning would have to be connected to the dmem cgroup giving you a fixed chunk of VRAM and being allowed to pin up to that limit?
19:33 karolherbst: airlied: I have no idea how anything in Fedora works
20:38 mlankhorst: airlied: yeah, and perhaps similar for memcg :)
20:38 mlankhorst: But that also means that if the limit is decreased, memory will stay pinned
20:47 mlankhorst: need to think on how to handle svm though.