<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?
vliaskov has joined #dri-devel
<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)?
sgruszka has quit [Remote host closed the connection]
kxkamil2 has joined #dri-devel
kxkamil has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
<dolphin>
agd5f: I think on wifi side such calibration data resides under firmware
tursulin has joined #dri-devel
rauji___ has quit []
bmodem1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
dtmrzgl has quit []
dtmrzgl has joined #dri-devel
bbrezill1 has quit []
bbrezillon has joined #dri-devel
<DavidHeidelberg[m]>
MrCooper: the goal is to match, when file was changed and exist (which should imply creation)
Leopold___ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
Guest3048 has quit [Remote host closed the connection]
swalker_ has joined #dri-devel
swalker_ is now known as Guest3055
oftcirc has joined #dri-devel
oftcirc has quit [Remote host closed the connection]
<Venemo>
does someone here understand how return values are supposed to work in NIR?
<Venemo>
nir_jump_return talks about some deref passed from the caller, but what if the shader doesn't have that
djbw_ has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
itoral has quit [Quit: Leaving]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
sgruszka has joined #dri-devel
heat_ has joined #dri-devel
jewins has joined #dri-devel
<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
fab has quit [Quit: fab]
<Venemo>
jenatali: what if there is no caller
<jenatali>
Then who are you returning a value to?
kzd has joined #dri-devel
smaeul has quit [Ping timeout: 480 seconds]
bmodem1 has quit [Ping timeout: 480 seconds]
yuq825 has quit []
<gfxstrand>
Venemo: Yeah, we don't model return values in any real sense. Return is just control-flow. Everything is void.
<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.
<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.
<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
<jenatali>
Just like the C++ ABI because LLVM
<gfxstrand>
Well, LLVM SSA values can be structs of arrays of crap, though.
<gfxstrand>
NIR is more limited there.
fab has joined #dri-devel
<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.
<gfxstrand>
We also don't have to figure out what to do with them in nir_lower_returns
<gfxstrand>
And those are all the things that touch functions, really.
fxkamd has joined #dri-devel
bmodem has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
pochu has quit [Quit: leaving]
<jenatali>
Yeah, so far anyway. Until karolherbst has his way and functions stick around to the backend
smaeul has joined #dri-devel
<karolherbst>
I mean.. treating the return value as a pointer to storage should be fine...
<karolherbst>
backends can optimize that to registers if they feel like it
<karolherbst>
function_temp is already stack memory and gets optimized to ssa values if possible
oneforall2 has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
oneforall2 has joined #dri-devel
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
<Venemo>
jenatali, gfxstrand I want to have a return value from the main function somehow
mbrost_ has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
Venemo: we're going to need a lot more info than that :-D
<Venemo>
basically I want to model the ac return values in nir somehow
<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
<jenatali>
"ac"?
flibit has quit []
lynxeye has quit [Quit: Leaving.]
<Venemo>
we have ac_shader_args for modeling the initial register state of waves
bmodem has quit [Ping timeout: 480 seconds]
<Venemo>
it has shader args that represent input registers, and it also has returns that represent output registers
mbrost has quit [Ping timeout: 480 seconds]
<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
<jenatali>
Ah, I see
<jenatali>
Can you add derefs as function args for the outputs?
<Venemo>
uhh, I don't know, I really hate dealing with derefs
<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
<jenatali>
Seems reasonable
mbrost_ has quit [Ping timeout: 480 seconds]
<Venemo>
thanks
<alyssa>
Venemo: for ESO on AGX, I was planning to add store_arg_agx intrinsics (or something like that)
<alyssa>
there are some slightly tricky details around SSA-based RA
<alyssa>
but I think ACO already has all that code for epilogs
<Venemo>
yeah, kind of
<Venemo>
but they are currently very radv specific
<jenatali>
Am I supposed to know what ESO stands for?
<Venemo>
ESO = VK_EXT_shader_object
<jenatali>
Ah
<Venemo>
sorry I thought this is how everyone around here was calling it
<jenatali>
It makes sense, and I'd probably seen it before, I just haven't seen it in a few weeks
<alyssa>
oh I still need to record that song about ESO
<alyssa>
i already have my mic set up from earlier--
<alyssa>
wait no fixing discard() regressions is higher priority nvm
<jenatali>
I usually see that acronym talking about Elder Scrolls Online so I was confused for a bit lol
<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
alyssa has left #dri-devel [#dri-devel]
tzimmermann has quit [Quit: Leaving]
<dcbaker>
karolherbst: yes. We should be able to force that. I’ve thought about that before and just never wrote the code
<karolherbst>
there is also `bindgen --version --verbose`
<karolherbst>
not sure if it prints the version of the thing it compiled against or runs against
<karolherbst>
but it's all kinda weird
benjaminl has joined #dri-devel
jewins has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Quit: leaving]
Guest3055 has quit [Remote host closed the connection]
i509vcb has joined #dri-devel
fxkamd has quit []
ngcortes has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
kts has joined #dri-devel
smiles_ has quit [Ping timeout: 480 seconds]
CATS has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
<karolherbst>
MrCooper: I found out today, that the nouveau overloaded virtual warning can also be disabled via -Woverloaded-virtual=1
<karolherbst>
maybe we should use that instead and I kinda plan on adding it in some non annoying way
<karolherbst>
it's annoying that at `Wall` it's using the 2nd level
<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.
<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)?
DPA has quit [Ping timeout: 480 seconds]
<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.
<cmarcelo>
kusma: should we be static linking libstdc++ instead?
<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.
<cmarcelo>
will watch the video, thanks :)
<kusma>
Np
DPA has joined #dri-devel
<gfxstrand>
C forever!
<gfxstrand>
Until we switch to rust. :-P
<bylaws>
What's the problem with multiple libc++ versions in the same process?
<bylaws>
This very much happens all the time in android so curious what's different in linux
DrNick has joined #dri-devel
<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
<jenatali>
Android has linker namespaces. The glibc linker doesn't
<DrNick>
e.g. Battleblock Theater won't run anymore without a binary patch, and Team Fortress 2 was broken for a bit
<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
<bylaws>
Oh so the issue is games not static linking libcpp and shipping their own?
<bylaws>
Fair enough
<DrNick>
that too
<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
<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)
<cmarcelo>
jenatali: if both dynamically linked you mean? if either mesa or game static link, there's no problem right?
<jenatali>
As long as the symbols that are statically linked are also hidden, then sure that's fine
<jenatali>
Hidden and non-relocatable
<karolherbst>
why does the glibc linker refuse to implement this though?
<karolherbst>
especially as this is such a painful problem
<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
<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
<bylaws>
It's cute, they use it for enforcing what libraries vendors use in their blobs
<jenatali>
Yeah. I'm well aware
<airlied>
glibc has the dlmopen but it doesn't seem to either work or be what people need
<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
diego has joined #dri-devel
pac85 has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
<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)
djbw_ has joined #dri-devel
<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?
<psykose>
it adds a bunch of size that doesn't have to be added because the libstdc++.so is already there
<milek7_>
couldn't symbol versioning be abused for scoped symbol resolution?
<DrNick>
that's how libstdc++ works now
<DrNick>
the problems crop up when the app ships a stale copy of libstdc++ that gets loaded before the newer system copy
<DrNick>
or when people make the mistake of putting STL containers or other types in their ABIs
<eukara>
pac85: what's the proper 'fix' for this? been unable to run one of my fav games for a while because of this
<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
<karolherbst>
eukara: normally you just remove the libstdc++ the game ships and hope it works
<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
<milek7_>
well, libc++ types in ABIs would blow up on windows too?
<DrNick>
yes
<milek7_>
and libc allocators might be different, so existence of CoTaskMemAlloc and others
<DrNick>
the history of Microsoft can be viewed through a lens of trying to make C++ useful in an ABI
<DrNick>
which is how you get COM and WinRT and so on
<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?
<jenatali>
We need to prevent Mesa from calling into C++ runtime code that comes from a different version than was linked against, yeah
<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
<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.
<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
<mattst88>
tbh, I'd worry about solving this problem if it actually happens
<HdkR>
I'm also exposing C++ over my library ABI. I need to fix that at some point. It's spooky.
<DrNick>
you can expose C++ in your library ABI, but you have to reinvent COM to do it
<jenatali>
I don't see how COM is related to C++ ABIs
<DrNick>
basic C++ features like constructors and destructors can't be used in your ABI
<HdkR>
Nah, I'm just going to shift everything over to C interfaces to be safe :)
<DrNick>
because they inline object size and layout
<DemiMarie>
What is the reason for Mesa dynamically linking to libc++ and LLVM?
<jenatali>
*on Linux
<jenatali>
On Windows we statically link it all in
<karolherbst>
$distributions
<DemiMarie>
Could one option be to run the LLVM stuff in a dedicated subprocess?
<milek7_>
microsoft have weird history with libc++ stability
<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
<DemiMarie>
karolherbst: drop support for dynamic linking?
<karolherbst>
I mean... sure, why not, but distributions will come around with torches
<DemiMarie>
What about dlmopen()?
<milek7_>
and eg. sleep_for is broken for years because they keep old abi
<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.
<DemiMarie>
Distributions need to get better at cascading rebuilds anyway
<karolherbst>
DemiMarie: tell that to game publisher
<HdkR>
DemiMarie: My plan is to be stable at some point for my little slice of the world at least
<DemiMarie>
karolherbst: presumably HdkR isn’t shipping a C++ ABI for use in Mesa.
<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
<HdkR>
DemiMarie: Emulated games with GL/Vulkan punched through to native libraries
<karolherbst>
DemiMarie: the problem isn't binaries being build incorrectly :)
<pac85>
If stdc++ is used by drivers and not by libgl couldn't mesa use RTLD_DEEPBIND?
<DemiMarie>
HdkR: report this as a Fedora bug
<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.
<mattst88>
I don't think this is helping
<DemiMarie>
mattst88: why?
<mattst88>
mesa isn't going to ship its own dynamic loader or invent something to run llvm in a separate process
<mattst88>
those are, tbh, rather absurd ideas
<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.
<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
<pac85>
DemiMarie: hasn't gnu recently broken the symbol table format? I don't like the idea of shipping a dynamic linker.
<DemiMarie>
“Linux doesn't have a good RPC story” what do you mean?
<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
<jenatali>
😅
<DemiMarie>
`execve(/proc/self/fd/<memfd>)`
<DemiMarie>
yes, you can spawn a process without ever touching a file on disk
<HdkR>
execveat is the better use
<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
<HdkR>
Also execve inside environments that might remove all your binaries breaks this :)
<HdkR>
Basically the world sucks and there's no "perfect" solution
<DemiMarie>
HdkR: that is why I suggested a memfd
<DemiMarie>
That said submitting patches to glibc is the best option.
<psykose>
glibc isn't the only libc in the universe
Company has quit [Quit: Leaving]
<DrNick>
we're talking about Linux though, not non-Linuxes like Android
<heat_>
*cough cough* musl *cough cough*
<DrNick>
or non-Linuxes like Alpine
<pac85>
Why is llvm a problem? I mean games don't ship their llvm so why would it be problematic?
<jenatali>
Are there other libcs besides glibc and musl that have this problem?
<pac85>
You mean the problem of not having namespaces symbols?
<jenatali>
Yeah
<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
<jenatali>
Heh, guess I should've added "relevant" to my question
<pac85>
jenatali: I think the BSDs do the same thing but I'm not 100% sure
<DemiMarie>
jenatali: maybe at least musl can be persuaded to take a patch?
<DrNick>
that assumes the BSDs are relevant
<DemiMarie>
DrNick: They are
<DemiMarie>
Maybe not for proprietary games but they are for Mesa in general
<psykose>
alpine is a linux distro like others
<psykose>
glibc = linux is a hilarious way to think about it i guess
<karolherbst>
BSD is relevant for Mesa? I doubt that
<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
<karolherbst>
well they can't
<pac85>
Why?
<karolherbst>
as publishers are not republishing games because of trivialiaities like this
<pac85>
I mean sure
<karolherbst>
some don't even have linux teams anymore, so the binary stays as is forever
<DrNick>
musl is very much a CADT "throw everything out and start over" product that isn't worth seriously considering
<pac85>
i meant as a game developer who wants to ship a proper game
<gfxstrand>
dcbaker: How do we assert particular rust versions in meson?
<pac85>
Would that be an option?
<karolherbst>
it doesn't fix the issue with broken binaries
<dcbaker>
and I spelled rc two different ways in 1 line... sigh
<pac85>
But is symbol resolution the only thing preventing multiple versions of the same library to live in the same process?
<psykose>
DrNick: that should be officially put in a readme somewhere for mesa then, i.e. "only glibc is supported"
<psykose>
you should propose such a change
<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
<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
<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?
<mattst88>
pac85: that wasn't my idea, but I don't think it would
<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)
<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
<mattst88>
I look forward to y'all's patches to run the shader compilers in a separate process
<DemiMarie>
DrNick: not if the out-of-process compiler is statically linked and starts with an empty environment
<gfxstrand>
dcbaker: Thanks! That works modulo the typos. :)
<DemiMarie>
mattst88: then static linking is the only good solution I can think of.
<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
<karolherbst>
ever implemented a custom dynamic linker?
<DemiMarie>
pac85: maybe? though honestly trying to ship a game for desktop Linux except via Flatpak is probably a bad idea
<dcbaker>
gfxstrand: I've learned the value of the phrase "something like" due to all the typos :)
<gfxstrand>
dcbaker: :D
<gfxstrand>
Wise
<karolherbst>
reminds me that I might want to check for the rustc version as well
<DemiMarie>
karolherbst: no, but GHC (Glasgow Haskell Compiler) wrote their own linker for `.a` files, which I imagine is even harder
<karolherbst>
why would it be?
<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
<karolherbst>
it's just merging some things
<DrNick>
no that's easier, static linking is extremely simple compared to dynamic linking
<DemiMarie>
That said I still think the best solution is to fix glibc
<DrNick>
glibc is under new management, you might be able to convince them
<karolherbst>
:D
Guest3100 has joined #dri-devel
<pac85>
karolherbst: nope. I suppose you are suggesting that it is theoretically possible but not pratical?
<karolherbst>
something like that
<DemiMarie>
What about bundling the OpenBSD dynamic linker?
<DemiMarie>
Or a fork of it
<karolherbst>
but I think nobody wants to do it
<karolherbst>
uhhh
<karolherbst>
no
<mattst88>
lol
<gfxstrand>
I *think* NAK is going to stick to 1.17.0
<pac85>
I'm not suggestinf bundling anything btw
Guest3100 has quit [Remote host closed the connection]
<mattst88>
this channel...
<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
<karolherbst>
gfxstrand: fair
<pac85>
My idea was a tool external to both the gamr and mesa
<karolherbst>
gfxstrand: distributions will hate you though
<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.
<mattst88>
#dri-devel-pontificating
<gfxstrand>
karolherbst: If distros are shipping NAK this year, I'm going to hate them. :-P
Malaph has joined #dri-devel
<karolherbst>
:D
<karolherbst>
fair enough
<karolherbst>
yeah.. the next FireFox ESR probably needs something newer than 1.70 so that should be fine :D
<dcbaker>
gfxstrand: btw, Did Xavier ever message you? He's been doing a bunch of Meson + cargo work
<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
<DemiMarie>
In fact I have often wished that the kernel drivers were part of Mesa
<gfxstrand>
dcbaker: I've chatted with him a little bit but not much.
<gfxstrand>
dcbaker: I thought he wasn't a fan of the meson cargo stuff ;-)
<DemiMarie>
As someone who is concerned about supply chain attacks: please use as little from crates.io as possible
<karolherbst>
DemiMarie: nobody wants to though
<karolherbst>
same as nobody wants to ditch libclang use by writing our own C frontend
<dcbaker>
One of the other gstreamer devs started working on it with me and convinced him it was worthwhile
<karolherbst>
DemiMarie: probably serde and syn
<dcbaker>
Demi: the plan we have (gstreamer devs and I) is that we'll have support for vendored dist tarballs
<pac85>
DemiMarie: how so you suggest to fetch crates?
<gfxstrand>
There's a few crates that are pretty much necessary if you want proc macros (which we do): syn, quote, and proc-macro2
<dcbaker>
but also we'll likely by default have pinned versioning anyway
<DrNick>
use Google's cargo vet list
<gfxstrand>
There's a handful of others that do something sufficiently obvious that I'm not too worried.
<DemiMarie>
yup, Google’s cargo vet list is a good idea
<gfxstrand>
But generally we plan to keep our list of crates small
<karolherbst>
we don't even use many native deps
<gfxstrand>
I'm happy to have a CI lint thing that checks against the Google list
<karolherbst>
yeah, same
pac85 has quit [Remote host closed the connection]
pac85 has joined #dri-devel
<DavidHeidelberg[m]>
Demi: bundling more stuff sounds terrible :D I always loved how mesa over its own complexity most often builds fine everywhere
<gfxstrand>
Yeah, but we really don't like having to build everywhere. :-P
agd5f has quit [Read error: Connection reset by peer]
<pac85>
I mean after all it isn't really a mesa problem, it's a gnu linker problem
TMM has joined #dri-devel
<DavidHeidelberg[m]>
gfxstrand: you'll have some serious explaining why Mesa won't run on my headless touster :P
sima has quit [Ping timeout: 480 seconds]
AndroUser2 has joined #dri-devel
pac85 has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
AndroUser2 has quit [Remote host closed the connection]
agd5f has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Leopold__ has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
gouchi has quit []
Malaph has quit []
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
<Kayden>
wow, some crazy ideas in the backlog
<karolherbst>
glad you like them
mbrost has joined #dri-devel
<Kayden>
I don't
<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
iive has joined #dri-devel
<karolherbst>
sounds fun
<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
<karolherbst>
yeah...
<karolherbst>
I mean... in the end it's just C++ being silly here and not specifying a proper ABI
egbert has quit [Ping timeout: 480 seconds]
egbert has joined #dri-devel
<cmarcelo>
Kayden: Cmm = C "minus" "minus"?
<cmarcelo>
:-D
<Kayden>
one of at least 12 languages called that, with zero docs, yes
Haaninjo has quit [Quit: Ex-Chat]
<DrNick>
imagine if C++ had the foresight to generate vtable and object layouts at runtime like Swift
rasterman has quit [Quit: Gettin' stinky!]
<jenatali>
Looks like several CI runners are out to lunch