<zmike>
or maybe you're doing one more pass with the backport scripts before
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
bonzini has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
bonzini has joined #dri-devel
guludo has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
rtauro2 has quit [Ping timeout: 480 seconds]
bonzini_ has joined #dri-devel
bonzini has quit [Read error: No route to host]
f11f12 has left #dri-devel [Leaving]
<eric_engestrom>
zmike: yes, its last two commits are in 25.2 :)
<zmike>
tremendous
<eric_engestrom>
I just did the final pass of backports
<zmike>
thanks
<eric_engestrom>
now in CI, and if it comes back green, that's 25.2.0 final
LeviYun has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
kts has joined #dri-devel
SquareWinter68_ has joined #dri-devel
SquareWinter68 has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
nerdopolis has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
alarumbe has joined #dri-devel
LeviYun has joined #dri-devel
epoch101 has joined #dri-devel
warpme has joined #dri-devel
feaneron has joined #dri-devel
YuGiOhJCJ has quit []
cmichael has joined #dri-devel
cmichael has quit [Quit: Leaving]
ctdsyl^ has quit [Ping timeout: 480 seconds]
rtauro has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
ctdsyl^ has joined #dri-devel
vedm has joined #dri-devel
dolphin has quit [Quit: Leaving]
kzd has joined #dri-devel
warpme has quit []
rasterman has joined #dri-devel
phasta has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
siak has joined #dri-devel
epoch101 has quit []
LeviYun has joined #dri-devel
bonzini has joined #dri-devel
bonzini_ has quit [Ping timeout: 480 seconds]
coldfeet has quit [Quit: Lost terminal]
siak has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
soreau has quit [Ping timeout: 480 seconds]
bonzini_ has joined #dri-devel
warpme has joined #dri-devel
bonzini has quit [Ping timeout: 480 seconds]
warpme has quit []
LeviYun has joined #dri-devel
bolson has joined #dri-devel
warpme has joined #dri-devel
leo60228- has quit []
leo60228 has joined #dri-devel
epoch101 has joined #dri-devel
urja has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
urja has joined #dri-devel
<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)
warpme has quit []
<MrCooper>
karolherbst: --wipe?
<karolherbst>
sure, but it's still annoying
<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
<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)
<karolherbst>
not saying it should be checked on each build
<karolherbst>
just on reconfigure
epoch101_ has joined #dri-devel
Guest23602 has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
<karolherbst>
but I don't buy the rustup argument, same would happen with ccache or any other wrapper around a compiler
<karolherbst>
anyway, not gonna engage in that upstream issue
stewi has quit [Remote host closed the connection]
<eric_engestrom>
fair
<dcbaker>
karolherbst: with rust?
<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
LeviYun has quit [Ping timeout: 480 seconds]
<karolherbst>
e.g. because mesa requires a new version
<karolherbst>
not really rust specific tho
<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
<karolherbst>
if a project requires gcc-11 out of hte sudden and the cache is still 10.something you'd have the same issue
<karolherbst>
dcbaker: I mean... you have the same issue wiht literally every compiler wrapper
<dcbaker>
it doesn't happen for ccache actually
<dcbaker>
because ccache is either a symlink or detected as a separate binary
balrog_ has quit []
<dcbaker>
so ninja's stat'ing does the right thing
balrog has joined #dri-devel
<dcbaker>
it's unique to a wrapper that proxies commands the way that rustup does, which is actually not very common
<karolherbst>
so meson has special handling for ccache?
<dcbaker>
yeah, and for scache
<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?
<dcbaker>
No, because rustup hides what it proxies
<karolherbst>
but then it would also not work for literally any other rnadom cc wrapper, would it?
<karolherbst>
like if I use a gcc_wrapper.sh, how would meson be able to detect that gccs version changes?
<dcbaker>
If gcc_wrapper.sh doesn't change it can't
<karolherbst>
okay, so it's not a rustup specific issue
<dcbaker>
it is in that no other compiler wrapper in common use works like rustup does
<karolherbst>
I don't see how that's relevant really, given there are compiler wrappers that don't work like the CC ones do?
<dcbaker>
Meson's special handling of ccache is "look for ccache, look for $CC, make a command of [ccache, $CC]"
<karolherbst>
sure
LeviYun has joined #dri-devel
<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.
<karolherbst>
why is that "weird"?
<karolherbst>
just because ccache does intercept --version?
<karolherbst>
or does something else to make it detectable?
<mareko>
having ccache in PATH works for me
<karolherbst>
like you use the implementation detail of specific projects to argue that every other project not doing it is "weird" or "hides" things
<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
<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
<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
<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/`
<karolherbst>
but I thought stat on the compiler bin for ccache doesn't work?
<karolherbst>
like it only works because meson detects ccache and special handles it
<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"
<karolherbst>
well I'm not asking meson to do that
<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?
<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
<dcbaker>
The problem is we really need something from rustup that's not a command to run that we can stat
<dcbaker>
but that's really tricky (to be fair to them) with their per-folder configurations
<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
<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
bonzini has joined #dri-devel
<karolherbst>
right.. I do agree that having to parse their settings.toml file is a bit more work
<dcbaker>
But you can also have a ./.rustup/settings.toml, right?
<karolherbst>
(and potentially unreliable when the format changes)
<karolherbst>
dcbaker: within the directory?
<karolherbst>
*project directory
<dcbaker>
yeah
<karolherbst>
mhhh
<karolherbst>
never seen that one
<karolherbst>
but I could try if it works
<karolherbst>
mhh
<karolherbst>
doesn't seem to do anything
<dcbaker>
I guess not, not sure if that was an old way or I'm just misremebering?
<dcbaker>
It says in the docs it goes in ${RUSTUP_HOME}/settings.toml like you said
urja has quit [Read error: No route to host]
<karolherbst>
yeah
<dcbaker>
but it also says in the docs "this is all implementation details, use the cli"
<karolherbst>
I mean.. a lot of things are implementation details, but things rely on it anyway
<karolherbst>
if something changes and we just get a supoptimal behavior out of it, so be it
<karolherbst>
so in theory meson (or rather ninja) would have to stat the settings.toml file and the actual rustc binary, right?
<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)
<karolherbst>
right.. rustc --version would be robust
LeviYun has quit [Ping timeout: 480 seconds]
<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
<dcbaker>
stating the settings.toml would be a rough proxy I guess, you might get some spurious rebuilds...
<dcbaker>
s/rebuild/reconfigure
urja has joined #dri-devel
<karolherbst>
yeah whatever tho
<karolherbst>
though
<karolherbst>
couldn't you depend on rustc --version if the stat changes?
<karolherbst>
uhm.. run
<karolherbst>
and only rebuild if the version actually changes after that
<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?
<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
<karolherbst>
yeah, I get it
<dcbaker>
honestly, I hadn't thought of stating the settings.toml and that... would be a pretty good aproximation
<karolherbst>
like for me it would be fine if "reconfigure" would do it
warpme has quit []
<dcbaker>
there would still be corners... but it would work in like 99% of cases
<karolherbst>
but now I have to wipe the entire build directory, because meson refuses to configure with the old version
<karolherbst>
rustc --version is fast, I'm sure it won't impact reconfigure times at all
<jannau>
isn't stating settings.toml broken if the default toolchain is just stable / nightly?
<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
<karolherbst>
jannau: you'd state the rustc binary _and_ settings.toml
<karolherbst>
*stat
<karolherbst>
settings.toml because you might have to check a different rustc binary after it changes
LeviYun has joined #dri-devel
<jannau>
how do you get the rustc binary? it's a hard link of rustup in the rustup case
<karolherbst>
though the big question is what happens if any of those impl details of rustup change and meson falls apart
<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
djbw has joined #dri-devel
<dcbaker>
rustup which rustc gives you the actual binary
<karolherbst>
ohhh, didn't know that...
<karolherbst>
mhh
<karolherbst>
that also parses settings.toml...
<dcbaker>
honestly, checking for rustup and running using that to get the binary would help in a bunch of cases
<karolherbst>
yeah...
<karolherbst>
if rustup is in your path then you probably use it
<dcbaker>
at least that would fix the rustup udpate case...
<karolherbst>
well could always stat settings.toml and check if rustup which rustc changed its output
<karolherbst>
but not having to actually parse that file does simplify things
<karolherbst>
or know the internal directory structure
<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...
<karolherbst>
another check: compare "$(rustup which rustc) --version" with "rustc --version"
<karolherbst>
if that matches it's _very_ likely that rustup is used
LeviYun has quit [Ping timeout: 480 seconds]
<karolherbst>
I think in theory you could have a rustup in your PATH but not ~/.cargo/bin
<karolherbst>
some distros also ship rustup
<jannau>
if rustup is in path and is identical to rustc rustup is used
kts has joined #dri-devel
<dcbaker>
You can have that, since you can set $CARGO_HOME :)
<karolherbst>
jannau: ohh, yeah that would also work
<karolherbst>
but that kinda sounds like an implementation detail
<dcbaker>
on nixos rustc and rustup are both symlinks to something in /nix
<karolherbst>
I think the --version check would be more reliable therefore
<dcbaker>
just to be extra fun :)
<dcbaker>
I think so too, and doing that at configure time is fine
<karolherbst>
I meant to detect the use of rustup
<karolherbst>
but yeah
<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
<karolherbst>
cool
LeviYun has joined #dri-devel
<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
<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?
warpme has joined #dri-devel
<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 :)
warpme has quit []
LeviYun has quit [Ping timeout: 480 seconds]
<karolherbst>
dcbaker: might want to mention that the default value of RUSTUP_HOME is HOME?
<karolherbst>
ehh
<karolherbst>
HOME/.rustup
<karolherbst>
also the link in there is broken
<karolherbst>
but yeah, looks good
<karolherbst>
I already drafted it, so if you are fine with it, could just send it as is
<karolherbst>
ehhh wrong channel 🙃
LeviYun has joined #dri-devel
rtauro has left #dri-devel [#dri-devel]
lynxeye has quit [Quit: Leaving.]
deprecated-funderscore has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
bonzini has quit [Ping timeout: 480 seconds]
<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?
<zmike>
it varies by release
<zmike>
some are good
<zmike>
some are less good
<HdkR>
All the unittesting in the world can't catch all the bugs.
LeviYun has joined #dri-devel
ctdsyl^ has quit [Remote host closed the connection]
<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
<karolherbst>
like if everybody would use .1 and not .0 then .1 would be kinda full with regressions probably
<karolherbst>
or rather.. the regressions would be fixed later
zzyiwei has joined #dri-devel
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
<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
LeviYun has quit [Ping timeout: 480 seconds]
shankaru1 has joined #dri-devel
LeviYun has joined #dri-devel
shankaru has quit [Ping timeout: 480 seconds]
<K900>
I think we can afford this then
<K900>
Now that we have a cheap out to downgrade
kts has quit [Quit: Konversation terminated!]
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
<karolherbst>
airlied: you do I need to ping to get the spirv translator updated in fedora 🙃
<karolherbst>
but maybe it should be rebuild on each llvm/clang update automatically
<karolherbst>
*rebuilt
<karolherbst>
(same for other distributions not doing it already)
<karolherbst>
not sure their release cycles align with llvm tho, but..
sima has quit [Ping timeout: 480 seconds]
clamor has quit [Ping timeout: 480 seconds]
clamor has joined #dri-devel
epoch101_ has joined #dri-devel
elfcdd^ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101_ has quit [Ping timeout: 480 seconds]
<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
agd5f_ has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
FireBurn has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
LeviYun has joined #dri-devel
<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?
epoch101 has joined #dri-devel
agd5f has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: I have no idea how anything in Fedora works
epoch101 has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
clamor has quit [Read error: Connection reset by peer]
LeviYun has joined #dri-devel
Ermine is now known as Guest23619
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<mlankhorst>
airlied: yeah, and perhaps similar for memcg :)
<mlankhorst>
But that also means that if the limit is decreased, memory will stay pinned
LeviYun has quit [Ping timeout: 480 seconds]
<mlankhorst>
need to think on how to handle svm though.
bonzini has joined #dri-devel
LeviYun has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
epoch101_ has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
haaninjo has quit [Quit: Ex-Chat]
elfcdd^ has quit [Ping timeout: 480 seconds]
elfcdd^ has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Remote host closed the connection]
bolson has joined #dri-devel
bonzini has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
jsa2 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
feaneron has quit [Read error: Connection reset by peer]
feaneron has joined #dri-devel
apinheiro has quit [Quit: Leaving]
feaneron has quit [Remote host closed the connection]