ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Guest145 has quit [Ping timeout: 480 seconds]
stuart has quit []
heat has quit [Read error: No route to host]
heat has joined #dri-devel
mclasen has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
<Frogging101>
What's the thing that people use to figure out what the driver is spending time on that's causing frametime spikes?
<airlied>
gpuvis?
<Frogging101>
Yeah this might be it, thanks
nchery has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
bluepenquin has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
bbrezill1 has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
heat has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<Frogging101>
Why do games constantly compile shaders during gameplay anyway? Shouldn't that be a one-and-done during loading?
<airlied>
Frogging101: is it the game compiling it or the driver?
<airlied>
not all games can preload all their pipelines either
<Frogging101>
I couldn't say for sure. What I'm observing is severe stuttering during gameplay in Halo, but only the first time I play through that part of the level, it's smooth if I restart the game and go through it again until I get to a part I haven't seen yet
<Frogging101>
I assume that's due to the second time benefiting from cached shaders
alanc has quit [Remote host closed the connection]
<airlied>
is it a dx11 or dx12 game?
alanc has joined #dri-devel
<airlied>
but yeah it could also be dxvk just having no choice or the driver having to do it
<Frogging101>
DX11, I think
<airlied>
it's why Valve have the steam shader precaching thing
<Frogging101>
Why isn't that necessary on Windows? I wonder
<Frogging101>
If I'm seeing stuttering due to shader compilation, then I guess that means the pipeline was not in the pre-caching data that Steam downloaded
<Frogging101>
Right?
<Frogging101>
otherwise it would have compiled it before starting the game (I let it finish)
<mangix>
speaking of valve, i'm often amuzed how a bunch of installed games on my deck have "updates" every day
<mangix>
*amused
<HdkR>
Fresh shader caches is great :)
saurabhg has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<airlied>
Frogging101: the valve cache only works for common drivers built in distros
<airlied>
if you build your own it won't hel
<Frogging101>
oh I see
<Frogging101>
Is the cache keyed upon the exact driver version?
<Frogging101>
Version number and commit
<airlied>
no it from the radv and llvm binaries
<airlied>
either using a build note or timestamp
saurabhg has joined #dri-devel
<Frogging101>
Ah, I see.
<kurufu>
forgive my ignorance, but what would it take to support the old world style shaders in a vulkan driver? Could dx11 shadercode by translated to spirv keeping some/most of the optimization while asking the driver to kindly not try hard to optimize the incoming code, allowing for suboptimal PSOs?
<airlied>
kurufu: nope not really
<airlied>
pipeline libraries at the current atteempt at alleviating the pain
<kurufu>
hmm maybe im more asking why, because spirv is not representative of what fxc/dx11 bytecode offered or it would just be a much bigger mess of a change to vulkan?
<airlied>
a lot of the dx11 opts were around changing stuff that didn't affect the main shader code
<airlied>
but basic vulkan doesn't have those interfaces
<kurufu>
I see, thanks!
<airlied>
or at least you have to declare a whole new pipeline to change them
<airlied>
and declaring a whole new pipeline means recompiling all the shadesr in the pipeline
<airlied>
because vulkan has no real concept of deriving pipelines,
<airlied>
pipeline libraries is sorta the answer to it
<Frogging101>
airlied: I thought what gets downloaded from Steam is hardware and driver agnostic (assuming the application doesn't conditionally create different shaders), and fossilize-replay is what processes that data into shaders for my hardware/driver
<airlied>
Frogging101: I haven't kept up with the finer details, but I thought it was still tied to the local driver
<airlied>
tarceri: knows more about it than I
<tarceri>
Frogging101: I'm pretty sure they are sorted after steam collects them. I don't think we just pass every combination to every user. But Plagman is the one who can tell you for sure.
<Frogging101>
My confusion might be thinking that the pipelines are hardware agnostic when they may not be
<tarceri>
Frogging101: right so these are two different things, steam can collect and distribute the fully compiled shaders for a specific driver but it does also collect foz dbs and distribute those. At one point we had a "secure compile" feature built into radv for compiling them.
<tarceri>
I don't have visibility into the steam side, or its current status I just do whatever is needed to help support it :P
<Frogging101>
Oh, so Steam distributes both shaders (hardware/driver specific) and fossils (not)
<Frogging101>
So perhaps the fossils are incomplete if I still have stuttering after replaying them
<tarceri>
Yeah thats possible, game updates, new assests etc
TMM has joined #dri-devel
<Frogging101>
It's a bit weird with Halo, because it's as if every time I enter a new part of the same level, it's doing a bunch of work and stuttering. I wonder if it's doing something particularly cache-unfriendly
nchery has joined #dri-devel
<Frogging101>
It runs smoothly only after I have thoroughly looked around the room and observed the usual animations and effects for the first time
<tarceri>
the talos principle used to be pretty bad for that type of thing, although what your describing sounds worse
<Frogging101>
It's Halo 2 specifically. Halo CE didn't seem to do this (...as much, maybe it's just less intensive). Both are in the Master Chief Collection though
<Frogging101>
What would I delete if I wanted to test this anew? The cache is already warmed up so I won't see it anymore on levels I've already played
bmodem has joined #dri-devel
<airlied>
Frogging101: .cache/mesa_shader_cache
mwalle has quit [Quit: WeeChat 3.0]
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
bmodem has quit []
<Frogging101>
Nothing under .steam?
aravind has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Guest180 has joined #dri-devel
srslypascal is now known as Guest181
srslypascal has joined #dri-devel
danvet has joined #dri-devel
Guest181 has quit [Ping timeout: 480 seconds]
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #dri-devel
MajorBiscuit has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
sdutt has quit [Read error: Connection reset by peer]
thellstrom has joined #dri-devel
fab has joined #dri-devel
frieder has joined #dri-devel
thellstrom1 has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
mvlad has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
kts has joined #dri-devel
<MrCooper>
karolherbst: FWIW, Mesa's CI is already using rustup
<danvet>
jani, but I get it already when merging drm-intel-fixes, so maybe more backmerging needed?
<danvet>
since whatever amdgpu conflict there is, rc1 should have it
<danvet>
hm maybe rolling drm-fixes forward will help, need that anyway for the backmerge
<danvet>
airlied, ^^ fyi I rolled drm-fixes to -rc1
<danvet>
6.0-rc1 ... how fancy
<danvet>
hah, now the conflict is already in drm-misc-fixes
<danvet>
mripard, mlankhorst there's patches stuck in drm-misc-fixes that didn't go out during the merge window?
<danvet>
can either of you do pls do a pr asap?
<danvet>
tzimmermann doesn't seem around
JohnnyonF has joined #dri-devel
jfalempe_ has joined #dri-devel
jfalempe has quit [Read error: No route to host]
srslypascal has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
<danvet>
jani, I think I have something now, build-testing, will push and ping you
<danvet>
since now the last conflict is in the CI topic branch, I guess that one needs a rebase
<danvet>
assuming it does indeed build before this point
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<danvet>
jani, seems to build, pushed what I have, I think I'll leave topic/core-for-CI up to you, ok?
<danvet>
hm no server rejected, needs more tricks :-)
<danvet>
ok now it's pushed
<MrCooper>
eric_engestrom: FWIW, in principle it should be possible to run macOS jobs directly in GitLab CI, e.g. gstreamer is doing so
fab has joined #dri-devel
<eric_engestrom>
oh? I thought macos runners were a paid feature (and available only on gitlab.com)
pjakobsson has quit [Ping timeout: 480 seconds]
<eric_engestrom>
thanks for the heads up, I'll have a look at how they do it
pjakobsson has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<mripard>
danvet: done
aravind has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
<lina>
Hi! I’m going to start working on a proper DRM kernel driver for the M1/M2 AGX GPUs tomorrow, and I’ve been leaning towards writing it partially or fully in Rust. I’d love to hear the opinion of the DRM team on that idea!
<lina>
The main reason for doing it in Rust is that these GPUs have pretty complex firmware structures that the kernel has to track and maintain, and it feels like it should be a lot easier to avoid usage/ownership/etc issues in a safe language.
<emersion>
i'm worried a bit about the Rust language complexity
<lina>
With how complex the firmware interface is, I don't think doing it in C would end up being any less complex, unfortunately...
devilhorns has joined #dri-devel
fab has quit [Quit: fab]
<lina>
Rust isn't really all that complex though (and I'm actually pretty new to it, I'm a lot more familiar with C, so I probably wouldn't be doing anything overly complicated in it)
<emersion>
ehhh
<emersion>
Rust as a language is much more complicated, has much more features than C
<lina>
Yes, but it doesn't mean you have to use all those features... kernel C also has a lot more features than standard C, they are just APIs that aren't part of the language, right?
<emersion>
well, idiomatic Rust does use all of these features
<emersion>
using a library feature (kernel API) is pretty different from using a language feature (Rust)
<lina>
I don't think that's how it works... idiomatic code doesn't mean you have to use every last language feature, or use them in a way that is hard to understand...
<emersion>
that's nmot what i'm saying
<emersion>
not*
kmn has quit [Ping timeout: 480 seconds]
<emersion>
i guess the gist of it is that i find C or Zig or Hare a better tool for the job of writing kernel drivers than C++ or Rust
<lina>
Well, Rust is about to become a supported language in the Linux kernel, Zig and C++ aren't...
<lina>
I mean, I'm new to Rust and I could figure out how to write a proc macro in a day... It didn't really feel very different from writing C, other than some basic type system features and of course the borrow checker and largely automatic lifetime management...
<emersion>
also you'd probably need to spend a lot of time writing safe wrappers for the core DRM helpers
<emersion>
also finding reviewers will be complicated
<lina>
Of course, I'd be happy to help maintain that! I think the Rust-for-linux folks would be happy to help review things. I already spoke with them, and they said that starting out with unsafe abstractions is okay, and we can start documenting the preconditions of the APIs so that we can turn them into safe abstractions over time.
<emersion>
well, i don't know if i'm just dumb, but i've been writing a good chunk of rust, and i still can't figure it out
<emersion>
if you're going to write unsafe rust drivers, i'm not sure what the point of using rust is
<emersion>
but oh well, rust is the hot new thing, so no wonder people want to use it for every problem at hand
<lina>
That's not what unsafe means, just because an abstraction has unsafe APIs doesn't mean all the code is unsafe. The goal is to reduce the amount of unsafe code, it doesn't mean the whole driver has to have zero unsafe code.
srslypascal has joined #dri-devel
<lina>
I mean, I have two choices, C and Rust... I already have a prototype userspace driver written in Python, and given the choice, even though I don't really know Rust that well yet, I have enough C experience to know that it would be quite painful to do in that language...
kmn has joined #dri-devel
mclasen has joined #dri-devel
<emersion>
people have been writing full GL and Vulkan drivers in C
<emersion>
i can't imagine a display driver being more complicated than that
pjakobsson has quit [Ping timeout: 480 seconds]
<emersion>
anyways, i've said my piece, i'm sure you'll find plenty of people excited about rust as well
<lina>
Not a display driver, a render driver. The display driver is separate, and already exists in C, but it could use with some of the same Rust mechanisms (right now it isn't multi-firmware-version and that problem needs to be solved)
<lina>
mesa has higher-level preprocessing and build tooling to do things that would be quite painful to do in plain kernel C...
rahul_janga has joined #dri-devel
<lina>
Consider that every firmware version Apple adds and removes random structure fields, and we have to support a subset of firmwares we choose to support forever... And these structures are probably more complex than anything that has been done in kernel DRM so far.
<lina>
And that doesn't include any per-version conditionals, I need to push that still and so far I only have two supported versions...
<lina>
The kernel has to handle all these because all of this lives in GPU kernel VM space and is shared, there is no way to push this responsibility to userspace (plus it would make userspace have to keep track of firmware versions, which would be even more painful).
riteo has joined #dri-devel
<riteo>
hiiii!
<riteo>
emersion: I just posted the MR you asked me
<emersion>
ah cool
<riteo>
I tested it on debian by patching the version it used
<riteo>
I admit that it wasn't main, but this patch is an one line fix, so I'm pretty confident that it'll work even there
<riteo>
I can confirm from my tests that it fixed the memory leaks that valgrind reported though
<emersion>
riteo: lgtm, i'll leave a bit of time in case somebody else has a comment, please ping me in a few days to merge
<riteo>
great!
gawin has joined #dri-devel
<riteo>
well, I'll leave the channel for now. Byeeee!
riteo has quit [Quit: epic fix moment]
<gawin>
lina: I think emersion meant here more social aspect. From my experience when platform owner isn't using tool XYZ: review process is gonna be much longer and lower quality. (And worst of all they may have a problem to articulate what they want.)
<gawin>
for example recently gerdie made MR connected to modern c++ and r600. MR wasn't touched for some time, even though c++ is super popular and we have some people knowledgeable about r600.
rahul_janga has quit [Ping timeout: 480 seconds]
fahien has quit [Quit: fahien]
ahajda has joined #dri-devel
rahul_janga has joined #dri-devel
camus has quit []
camus has joined #dri-devel
<lina>
gawin: Of course! But this is going to be a pretty long term project (we can't exactly rush defining the UABI until we have a lot more confidence in how the driver works), so I hope that along the way I can drag some people along ^_^
rahul_janga has quit [Read error: Connection reset by peer]
pjakobsson has joined #dri-devel
fab has joined #dri-devel
fab has quit []
elongbug has joined #dri-devel
devilhorns has quit []
<airlied>
lina: go nuts with rust, and see how far you can get, i suspect it'll be a long journey, but i would be fine with seeing what it looks like
<airlied>
danvet: may have some opinions
devilhorns has joined #dri-devel
<lina>
airlied: Thank you! It's going to be a long journey for sure, though I'm kind of hoping I can get something rendering sooner rather than later ^^
<lina>
(I'm also going to have a lot of general questions along the way, unrelated to programming language choice, about how to architect the driver and UAPI...)
heat has joined #dri-devel
<danvet>
lina, airlied uh ...
<danvet>
so I think rust is pretty cool and there's benefits, what I'm worried about is commonality in design of drivers
<danvet>
like a huge benefit of upstream is sharing concepts and building great helper libraries
<danvet>
and we can do that with rust too ofc, but doing that with just one driver might end up worse
<danvet>
which ofc means there's a bit a chicken/egg thing going on
<lina>
The idea would be to abstract the existing DRM common code, not rewrite it in Rust!
<danvet>
well I'm not sure that works so great to get that nice native rust feeling
<danvet>
like some of the helpers we have are very much inspired by borrow checker patterns
<danvet>
and some are absolutely not
<lina>
It should, you just need to write an abstraction that makes the API idiomatic. In principle that can pretty much always be done (I think the Rust-for-Linux folks can help there too)
<danvet>
e.g. making sure you can't get the ww locking wrong or so
<lina>
But it also doesn't have to be perfect on the first try
<danvet>
yeah it's defo worth playing around
<danvet>
I guess the question is also how much are you willing/able to burn time on this
<danvet>
like if our overall refactor/cleanup bw is going to be limited because everything is held up in the rustification step, it's probably not great
<danvet>
and we might need to build more critical mass first in a more contained place
<lina>
I think burning time on the Rust abstractions is going to save me time in the long term on the driver, once we support enough GPUs/firmwares/etc!
<danvet>
also if you want to make this happen: I think if there's a 2nd driver team willing to do this fun, that pretty much solves all my concerns I think
<danvet>
hm yeah maybe there's enough benefit on the backend driver side of things
<lina>
But I don't think it should cause much additional workload for the rest of the team, since I can just write/maintain whatever abstractions I need. The only real bottleneck is that, of course, C API changes also need to touch the bindings then, but hopefully that's not too much extra friction...
<danvet>
thus far those have been kinda small
<danvet>
lina, it's not just c api changes need to touch bindings
<danvet>
it's we constantly move the subsystem forward and roll out new concepts and tools
<danvet>
if the rust drivers are stuck behind that's not so great and defeats the point a bit
<danvet>
but also I'd say as soon as it's drivers and not just a driver I can happily shut up about all this :-)
<lina>
Of course, but I'd want to use those tools (if they're useful for this GPU), I do intend to maintain this thing... ^^
<lina>
I can't say much about convincing other drivers though, because this is probably the first new driver to have good reasons to start out in Rust, and convincing others to rewrite in Rust is pretty tricky...
<danvet>
well with my subsystem maintainer hat on it's my job to worry about anything with a bus factor too close to 1 ...
<lina>
Chicken-and-egg problem as you say, maybe once I'm done others will want to try!
<danvet>
yeah it's tough, and long term I do think we'll need to get there eventually
<lina>
Ah, in that sense, I'm sure I'll drag other people into it as it moves forward
<danvet>
the other thing to keep in mind: a lot of these wrappers will be for stuff outside of drivers/gpu
<danvet>
plan in years for those bikesheds, if you want to be realistic
<lina>
Yes, I'm aware, e.g. dma_pool needs bindings too. But the RfL folks are interested in / already working on a lot of that stuff.
<danvet>
airlied and me can just land stuff that's not quite ready but the right next move in drm, but we can't play these games in other areas just to get something going for a better long term future
<danvet>
well the drivers thus far seem very limited, and gpu drivers tend to be far from limited
<lina>
Of course, though I think much of the basics are already covered, and for things like dma_pool *someone* is going to have to do it sooner or later (since tons of Rust drivers would need it)
<danvet>
so just all the basic stuff like irq handler, workers, all that stuff
<danvet>
tbh I have no idea how much of that exists already
<danvet>
also automagic cleanup for everything like devm/drmm
<lina>
Most of that is in there already as far as I know!
<danvet>
those are just enormous amounts of mostly rote work to roll out to everything
<emersion>
so with rust if someone touches core DRM they'll need to update Rust drivers as well?
<emersion>
that sounds very painful
<lina>
I looked at the Panfrost driver and it wasn't really hitting much API surface outside of DRM and really basic stuff that already exists or I don't care about, plus dma_pool/dma_resv/fences
<danvet>
emersion, well at first I think we need a well-staffed rust task for to help out with that
<danvet>
but yeah, long term this would mean that drm hackers need to learn rust
<emersion>
i don't want to touch any Rust code when contributing to core DRM
fahien has joined #dri-devel
<emersion>
well that's not very nice
<danvet>
personally I don't see it much different from forcing people to instally sphinx or learning the bazillion of linux-isms in C code
<danvet>
linux C is pretty far from anything resembling any standard userspace C
<danvet>
stuff like bespoke memory model and other fun things
<lina>
Updating Rust code for API changes isn't terribly hard, I think... and you don't have to update the abstractions for new functions, those can be added when necessary, only for things that would break the existing code.
<emersion>
i have no trouble writing C even if i don't know kernel stuff
<emersion>
i have a lot of trouble writing rust
<lina>
I don't know how things go in DRM land, but as far as I know most subsystem changes are adding features (that don't touch existing drivers), or fairly simple global changes (like renaming functions or adding a parameter). Changes that end up *requiring* nontrivial refactoring/rework of all consumer drivers aren't that common, right?
<lina>
It's not like doing the latter is easy, Rust or no Rust...
<danvet>
we do quite a bit of that in drm
<emersion>
we have many changes which touch all drivers
<danvet>
well, not done in a way that changes are required, because these flag days are impossible with anything bigger than a tiny team
<emersion>
core DRM isn't a stable API
<danvet>
but we do roll out pretty massive changes across the board all the time
<lina>
At that point don't you end up having to talk to everyone involved anyway? After all every driver maintainer would have to check over it and test it, right?
<danvet>
and the benefits of better semantics in helpers/core api don't work out if too many drivers are stuck on old concepts
<danvet>
lina, yes-ish
<emersion>
they just ack it in general
<danvet>
but also, if they dont, we just roll it out anyway and if there's any fallout, fix it up
<danvet>
with rust there's a considerable additional hurdle here
<lina>
If the rollout is not a flag day, then it shouldn't be a problem as long as I handle the Rust side, right?
<danvet>
at least until rust knowledge has arrived in pretty much everyone's head
<danvet>
lina, yeah, which brings us to the "are there going to be enough rust people to take care of this" around
<danvet>
and the bus factor question
<lina>
Right, and the chicken-and-egg problem ^^
<danvet>
my experience is that any team of one will burn out, guaranteed
<danvet>
yup
<danvet>
the only question is, will the burn out happen this year, this decade, or when you built an entire city on top of that one brick
<lina>
But it's going to be a long road, and I'm counting in luring some folks in... if nothing else, I'm sure some of the Rust-for-Linux folks would be interested.
<lina>
(Especially considering this will be a huge boon to their project)
<danvet>
like as an example, I'm talking since years with the kunit folks
<danvet>
only now do we finally seem to build some critical mass to get that going
<danvet>
similar with unit tests in general for drm helpers
aravind has quit [Ping timeout: 480 seconds]
<lina>
Rust-for-Linux has been going for a while now too, but it looks like it will finally be merged in a kernel cycle or two, that's why I want to take the chance
<danvet>
and sometimes these kind of fundamental shifts are decade long projects and still fail
* emersion
can't wait to have 10 langs in the kernel
<danvet>
lina, linus explicit reserved the right to toss it out again if it fails
<danvet>
so there's also a bit a risk involved in building a driver on this path
kts has quit [Quit: Konversation terminated!]
<lina>
I know, there's some risk
<danvet>
now don't get me wrong, I'm very happy that someone is a willing fool to try :-)
kts has joined #dri-devel
<lina>
But then again building something useful in it is good, right?
<danvet>
just be aware it could backfire badly
<danvet>
yeah I think absolute worst case we should learn a lot about good api/helper design
<danvet>
and a lot of that should transfer back to C
<danvet>
so "it was all for nothing" is imo very unlikely
<lina>
It's not like Rust can't be translated to C if it comes to that... in fact, just having something the borrow checker thinks is kosher would probably do a lot towards having the C version be bug-free even if it does come to that
<danvet>
yeah, dumping more borrow checker concepts into our helpers should help them a lot I think
<danvet>
all the atomic_get_state functions are pretty much built on that idea
<lina>
(Though in that case I'm really going to need some build system or, at the very least, ugly #include shenanigans... because I really don't think there is a maintainable way of doing the multiple firmware version support in C without that)
<mripard>
emersion: the slippery slope is usually not a very compelling argument
<emersion>
mripard: wdym?
<danvet>
yeah I think in 3+ decades rust is the first non-C in the linux kernel that's genuinely considered
<danvet>
at that pace we might add a new language every half-century
<mripard>
you're never going to have 10 languages in the kernel
<mripard>
we're talking about introducing a third one here
<danvet>
which means I'll retire (and pretty much everyone else here) before langauge no 3 shows up
<emersion>
why not?
<danvet>
mripard, what's the 2nd one?
<emersion>
danvet: rust and zig and hare and <new lang> are pretty new
<danvet>
kinda disregarding inline asm and that stuff
<mripard>
danvet: yeah, I meant all variants of assembly
<danvet>
emersion, 15 years
<danvet>
older than the oldest gcc we still support, so it's not that terrible
<lina>
danvet: On the flip side, if while wrapping DRM features in Rust I discover API design details that I think could be done better, do I get to propose them / do the cleanup on the C side?
<danvet>
mripard, well tbf I don't even really know x86 assembly
<mripard>
and even if we had 10 languages, if they all have merits and are tools fit for the problem they aim to fix, what's wrong with it?
<danvet>
that stuff is limited enough that you can't care
<danvet>
plus anything cross-platform (i.e. drivers) you need to program against the abstract linux kernel memory model anyway
<danvet>
lina, yeah that would be pretty solid sales pitch
<danvet>
even better if you can use that to drag maybe another driver into this idea
<lina>
Sounds good then!
<emersion>
danvet: zig is 6 years old, so with luck in 6 years we have zig in the kernel
<emersion>
(rust is 12 years old)
<danvet>
emersion, not sure who's even proposing zig?
<mripard>
Rust might not be the proper solution, but it's not like C is the perfect bullet. It's closer to a dumpster fire at this point.
<lina>
I don't really understand why some folks are scared of programming languages... they all have their pros and cons. I recently learned D to work on a project and I found it really neat, I'll probably use it for some future projects where it fits.
<emersion>
if rust is in there, why not zig? it's a good fit
<lina>
emersion: Propose it to Linus and start the project to add it to the kernel? ^^
<danvet>
emersion, I'd say anything that is not a fundamental improvement compared to rust will have no chance
<lina>
I keep hearing about Zig but as far as I know nobody has seriously proposed it for Linux...
<danvet>
same way C++ never landed, because fundamentally it's just a bikeshed on top of C
<danvet>
some of the rust stuff is genuinely a step further, and very hard to impossible to rebuild in C
<danvet>
lina, I think the trouble is idiomatic use
<danvet>
like learning a new human language to be a tourist is easy
<danvet>
learning one to pass as a native speaker is usually a ton of hard work
<lina>
That's fair, but honestly, if it's an existing project, I find it pretty easy to just copy the same style/idioms I see there already.
<danvet>
and linux C is already a very distinct dialect of C in that regards and tough to really learn at "native" levels
<javierm>
danvet: that's a great analogy and one I probably will use a lot in the future
<danvet>
lina, yeah, but we're also talking about building that up in a very specific niche
<danvet>
there's not a hole lot of native linux rust to copypaste from for best practices
<danvet>
so again back to the chicken/egg issue
<lina>
Of course, I meant for other people concerned about this!
<lina>
I know I have the hard work ahead
<lina>
(And I'm kind of counting on the RfL folks' help, but they're really friendly and eager to help)
<danvet>
lina, well even just building enough critical knowledge
<lina>
I'm not even very experienced with Rust, I'm much more familiar with kernel C
<danvet>
e.g. I'm having a fairly lengthy discussion with paulmck on locking engineering
<danvet>
and how for whatever reasons, drivers/gpu seems to suck a bit locally with critical mass on that topic
<danvet>
(discussion on twitter and some blogs)
<lina>
locking engineering, as in the primitives, or usage?
<danvet>
both
<lina>
(Both are complex)
<danvet>
since in the kernel sooner or later when you get fancy enough, you end up building primitives
<danvet>
but yeah even just properly designed locking without building new primitives
<mripard>
danvet: Yeah, btw, thanks a lot for those blog posts and twitter discussions
<lina>
Yeah, locking is hard, and I'm going to have to figure out how to architect that for this driver too...
<lina>
Speaking of, I'd love to have discussions about this kind of thing, especially with how it relates to this GPU, even without bringing Rust into it, because it's oddball enough that it would probably benefit from core API changes
<danvet>
lina, like if driver teams start yolo cargo-culting bad rust code in the same way they've managed to yolo bad locking engineering
<danvet>
then I'm deeply scared about the dumpster fire cleanup we'll have to do in 5 years or so
<danvet>
and maybe it's better if some other subsystem volunteers for that :-)
<lina>
I'm going to try to engineer this properly, that's why I want to try to do it in Rust!
<lina>
After I get the bring-up chores done, my first order of business is designing some kind of Rust abstraction/interface for GPU objects that gives good guarantees and makes it easier to juggle all the structs we need to make this thing run
<danvet>
people didn't set out to create horrendous locking designs either, but they still did
<danvet>
and collectively acquiring that knowledge for what good design is is a lot of work
<danvet>
in the human language comparison, essentially you'd get to teach an entire village a new language
<lina>
It is, and I don't expect this to be merged any time soon because I'm sure it will take a lot of self-discovery and refactoring to arrive at a good design in the end
<danvet>
excellent chances they actually just create some kind of creole thing
<danvet>
and if every subsystem creates their local rust creole, then linux is kinda screwed
<lina>
The good news is that enough people are excited about Rust that I really don't think it will be difficult to lure in some folks with experience to help design/review things ^^
<danvet>
we already have a pretty bad balcanization problem going on with local subsystem bikesheds
kts has quit [Ping timeout: 480 seconds]
<lina>
I think Rust also tries to fix some of that by building higher-level common code (and also things like having tool-enforced coding style, none of that every subsystem has their quirks business)
<lina>
(sorry, I'll be back in 10 minutes, need to head out for a second)
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
thellstrom1 has quit []
<lina>
(back!)
<lina>
danvet: Also, for what it's worth, I don't have any corporation paying my bills and expecting me to work on specific things, so I can choose to spend as much time as needed on design and refactoring to keep things clean. I think that probably counts for something ^^
<lina>
No deadlines, either!
paulk has quit [Quit: WeeChat 3.0]
srslypascal has quit [Quit: Leaving]
<Frogging101>
I'm with emersion on this, personally
mdnavare_ has joined #dri-devel
rsripada_ has joined #dri-devel
aswar002_ has joined #dri-devel
dolphin` has joined #dri-devel
dolphin` is now known as dolphin
sdutt_ has joined #dri-devel
elongbug_ has joined #dri-devel
Ryback_[WORK] has joined #dri-devel
srslypascal has joined #dri-devel
shankaru1 has joined #dri-devel
shankaru has quit [Ping timeout: 480 seconds]
mdnavare has quit [Ping timeout: 480 seconds]
rsripada has quit [Ping timeout: 480 seconds]
aswar002 has quit [Ping timeout: 480 seconds]
sdutt has quit [Ping timeout: 480 seconds]
elongbug has quit [Ping timeout: 480 seconds]
riteo has joined #dri-devel
<riteo>
hiii!
<riteo>
I noticed that my MR is stopped until the pipeline has succeeded, but it says it needs a manual action to continue
<riteo>
I don't know if I should start it or if there's a reason for said manual action requirement
<emersion>
the CI is only run when merging
<riteo>
oh ok
<daniels>
you can run it manually if you like, but running it for every push would be overkill compared to how much capacity we have
<riteo>
I won't waste CI time for a oneliner don't worry
<riteo>
I was just curious if I had to do anything since it was declared as blocked
<riteo>
but as long as it's intended I'm fine
fab has joined #dri-devel
kts has joined #dri-devel
<MrCooper>
lina: don't let yourself be discouraged by Rust nay-sayers :)
bmodem has joined #dri-devel
bmodem has quit []
kts has quit [Ping timeout: 480 seconds]
CosmicPenguin_ has left #dri-devel [#dri-devel]
<lina>
MrCooper: ^^;
CosmicPenguin has joined #dri-devel
srslypascal is now known as Guest215
srslypascal has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
<orbea>
MrCooper: people who like rust should spend more time building themselves from scratch, the state of the infrastructure is at the point that the quality of the language is a moot point
aravind has joined #dri-devel
Guest215 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
Net147_ has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Net147 has quit [Read error: Connection reset by peer]
<daniels>
the people who have got Rust-in-kernel support to the point where they can actually build things with it, and Linus who've said that he's very close to merging that support, presumably disagree with you, but ok
<orbea>
i presume money talks in that case
<MrCooper>
orbea: right, that's why there are no more memory handling bugs in the Linux kernel ;)
<orbea>
there is a lot of money behind mozilla and rust
<orbea>
memory handling bugs can be fixed
<orbea>
the amount of time lost navigating rust's infrastructure will never return
<orbea>
all I am saying, don't defer the suffering to others without knowing what it is yourself
<MrCooper>
I for one desperately hope I won't have to be messing around with C for the rest of my professional career
<MrCooper>
I have decades of experience dealing with C's shortcomings, I think I have a pretty good idea :)
<orbea>
I personally like C and I don't think its going away regardless if its good or not
<javierm>
orbea: the amount of time I personally lost dealing with memory issues in Linux will never return either
Dr_Who has joined #dri-devel
<MrCooper>
I like C as well :) But I'm painfully aware of its flaws
<orbea>
regardless i'm not arguing against the rust language, I'm arguing against the state of getting the rust language to work. Things should not fail an 1+ into the build because you have version 1.0.2 instead of 1.0.1 and there is a hardcoded version check the dev refuses to drop
<orbea>
an hour+ *
<riteo>
from what I heard that's the biggest flaw about rust
<riteo>
missing spec and unstable ABI
<Frogging101>
A step was skipped in not having a spec, indeed
<riteo>
IMO as long as I can compile linux with GCC only (which looks like something that'll be doable soon-ish), I'm all in for experimentation
<emersion>
well, another flaw is that you need to have a big brain to use it
<riteo>
soon-ish referred to when rust will be added*
<mripard>
I mean, most of the issues pointed out by the rust compiler are still very much there with C
<Frogging101>
That's good news. Having only one compiler wasn't great
<mripard>
the compiler just doesn't car
<riteo>
warning: I can't speak too much about rust as I've never used it and don't plan to
<orbea>
Frogging101: i've been told that clang largely works when building linux now
<mripard>
so imo you need a bigger brain to write equivalent code in C than in Rust
kts has quit [Quit: Konversation terminated!]
<riteo>
I like the idea but the implementation is horrible from what I heard, plus some other weird-ass philosophical things of mine
<ajax>
why should anyone spend any serious amount of time "building themselves from scratch"
<emersion>
mripard: my small brain is enough to write C, and experience has proven it doesn't contain many memory bugs
<emersion>
mostly because it isn't trying to be clever, and ASan
<mripard>
you should stop downplaying yourself then
<orbea>
ajax: people involved with distro maintainence have to do this and if they didn't using rust wouldn't be a reality. :P
<mripard>
you have a much bigger brain than mine :P
<emersion>
mripard: yet i can't do rust, no matter how many times i try and no matter how much code i write
<daniels>
if you don't want to see Rust merged into the kernel, then you should have that argument on lkml (or whichever shadowy organisation is paying Linus to merge it even though it's a terrible idea - it's not Mozilla because they got rid of all their Rust developers btw), not #dri-devel
<riteo>
I just wonder how rust would've been received if it used saner approaches for most stuff
<emersion>
daniels: Rust in the kernel is one thing, Rust in DRM is another thing
nchery has quit [Ping timeout: 480 seconds]
<riteo>
I think that a memory checker at compile time is actually a great idea, it's just rust that from what I heard did it in the worst way possible
<emersion>
as long as Rust is isolated in a place i don't need to touch, i don't care
<riteo>
(from the community, implementation, spec and whatnot side)
<javierm>
emersion: you mean in DRM user-space or kernel-space? Because once it makes into the kernel, it's just a matter of time to make it to all subsystems
<daniels>
DRM isn't an island; it cuts across so many things (mm, dmabuf/fence/etc, media, audio, ...) that if Rust is accepted as the kernel's third implementation language, it'll be inevitable that at some point you won't be able to avoid Rust, even if DRM gains a 'we'll never use anything other than C and assembly' rule
<Frogging101>
soon you'll be finding crabs in your closet and under your bed
<javierm>
emersion: re: learning rust - I also consider myself to not have a big brain and I had to actually read the full rust programming language book to wrap my head around rust
<riteo>
Frogging101: the rust mafia
<emersion>
i've read that one, yeah
<javierm>
emersion: usually I learn mostly by experimentation but in this case I needed to sit down and study the fundamentals
<orbea>
daniels: its a good point that the kernel and mozilla are forcing this regardless of what mesa does, but there are large financial interests there I don't even know how to approach...
<orbea>
#dri-devel is friendlier :P
<Frogging101>
I don't really think it's a case of unbalanced influence
<qyliss>
mozilla doesn't even have a rust team any more, does it?
<Frogging101>
Not this time
<mripard>
emersion: things like expressing the relative lifetimes of the structures or the locking conventions are still very hard to express in C (especially for DRM)
<qyliss>
they fired the whole team years ago at least. did they hire a new one?
<Frogging101>
And if anyone is moneyhatting it, it is not mozilla. Mozilla is poor.
<mripard>
and are definitely not checked by any tooling
<mripard>
orbea: what are those large financial interests?
<Frogging101>
So I'd say keep the debate to the technical side
<orbea>
various large corporate powers
<mripard>
which ones?
<qyliss>
the rust industrial complex
<javierm>
mripard: and also the error handling. That's one of the best things about rust IMO, people focus mostly on the memory ownership but algebraic types and the match pattern is awesome
<Frogging101>
orbea: don't torpedo your argument with this please
<mripard>
javierm: yeah, I wish I had algebraic types in C
<daniels>
javierm: ++
<riteo>
I think I know why hare and C are so appreciated by minimalists and whatnot
<mripard>
orbea: Mozilla, the non-profit org that barely has any money to work on its core business these days?
<Frogging101>
Rust in kernel has a strict policy of no crates, right?
<qyliss>
no cargo, even
<riteo>
c++ and rust feel like overkill for people who like to write the simplest and smallest programs. Those complex idiomatic features allow, and in a way encourage, bigger more complex programs
<mripard>
that large corporate power?
<Frogging101>
qyliss: That's good news. No-cargo implementations are important
nchery has joined #dri-devel
<orbea>
i'll take Frogging101's advice and shut up about it, its a deep rabbit hole where I dont know most of the answers
<qyliss>
Frogging101: yes, I agree. as a packager, 90% of the things i don't like about rust are actually cargo's fault.
<riteo>
Frogging101: yeah that'd remove one of the most criticized part of the ecosystem
<orbea>
^^^
<orbea>
cargo is the biggest issue
<riteo>
that's why I wonder how rust'd be seen by minimalists or skeptical people if it had a good ABI, a spec, multiple implementations and didn't insist on using that dumb cargo thing
<riteo>
things which are technically fixable and all outside of the syntax and the lang itself
<orbea>
i probably wouldnt complain about it at that point
<riteo>
that's why I say that it's a nice idea implemented in the worst way possible
<Frogging101>
riteo: I'd certainly be more favourable toward it
<riteo>
Frogging101: same thing
<qyliss>
last time I looked at rust-for-linux it just had rustc integrated into Kbuild
<riteo>
just to add context I'm one of those minimalists which like minimalist stuff like hare and want the simplest, smallest programs and logic
alyssa has joined #dri-devel
<mceier>
riteo: if it had done that, I wouldn't drop it at 1.0 version ;)
<alyssa>
yo I heard we were doing conspiracy theories in here
<alyssa>
here's mine: lina is actually danvet
<orbea>
riteo: tbf the gcc implementation may solve some of the pain
<riteo>
wait, is danvet the guy with the chip on the avatar on twitter?
<riteo>
don't recall the name, sorry
<orbea>
(i hope)
<riteo>
btw yes, we're doing conspiracy theories, someone get an extra hat for alyssa
<Frogging101>
alyssa: We need a conspiracy theory for how you knew what we were talking about
<riteo>
Frogging101: logs?
<Frogging101>
are there?
kts has joined #dri-devel
<riteo>
yup
<riteo>
oftc.logchat.whitequark.org/dri-devel
<Frogging101>
ah.
<Frogging101>
usually that kind of thing is announced in the topic
<riteo>
also lina's a friend of alyssa if those are not homonyms with the M1 linux project
<riteo>
...members*
<daniels>
my theory is that Big C is funding retrofetishism in order to hobble developer productivity
<riteo>
daniels: if this means no Web3 I'm all for it
<riteo>
brb joining on an amiga
<daniels>
that's ... one interpretation
<alyssa>
10:26 <lina> mesa has higher-level preprocessing and build tooling to do things that would be quite painful to do in plain kernel C...
<alyssa>
100% to this
<qyliss>
wow it sure gets confusing talking in here when somebody else's nick is my name (that I get highlights for)
<qyliss>
usually I just spectate #dri-devel so I can safely ignore all highlights…
<alyssa>
qyliss: sorry alyssa
<qyliss>
:D
nchery is now known as Guest222
nchery has joined #dri-devel
<riteo>
just to be sure, are alyssa, lina and danvet asahi linux developers or is it some coincidence?
<riteo>
that joke about lina being someone else is very familiar to me
<alyssa>
hmm?
<alyssa>
I'm a NixOS maintainer
<alyssa>
qyliss: is the Asahi Linux alyssa
<riteo>
oh now it makes sense
<qyliss>
alyssa: wow you're mean
<riteo>
alyssa: sorry for confusing you
<alyssa>
(/me is joking)
<riteo>
what
<riteo>
I'm confused now
<riteo>
who's who
<alyssa>
Anyway, joking aside:
<alyssa>
10:26 <lina> mesa has higher-level preprocessing and build tooling to do things that would be quite painful to do in plain kernel C...
<alyssa>
This is the crux of it for me
<Frogging101>
What does that mean, sorry?
<orbea>
alyssa: would raising the C standard be impossible?
<orbea>
c99 or c11 would probably be better in a lot of regards
<riteo>
the argument would become that the build tooling could improve on linux instead of pulling a whole component of an huge ecosystem
<qyliss>
orbea: the kernel is on C11 now
<alyssa>
Most big Mesa drivers rely *heavily* on either compiling the same file multiple times with different #defines and building a runtime dispatch table, generating C code as part of the build step (usually Python with Mako templates), or usually both.
<orbea>
oh
<orbea>
nvm then
<alyssa>
Mesa is really C11 + meson + python3 at this point
<daniels>
alyssa: you forgot C++ and also Rust :P
<alyssa>
If those kinds of games were acceptable in the kernel, the argument for Rust would diminish a lot
<alyssa>
daniels: Also that.
<alyssa>
daniels: I do my best to forget that the GLSL compiler exists
<riteo>
alyssa: didn't the linux build system already play with perl, at least in the past?
<daniels>
alyssa: ACO & Clover
<alyssa>
fair
<JoshuaAshton>
time to rewrite the dispatch generators in perl /s
<alyssa>
anyway, for AGX/DCP, if we could do multiple compilation + build-time Python scripts, the argument for Rust mostly goes away
<alyssa>
(mostly. the safety guarantees are still nice.)
<riteo>
I don't see how those build system games aren't allowed on linux
<alyssa>
Either the kernel depends on Rust or on Python. Currently this is swaying heavily towards Rust. \shrug/
<riteo>
alyssa: yeah, the issue is that that safety is pretty much the only pro, with a lot of cons against rust
<JoshuaAshton>
what is the kernel allowing for rust anyway, I assume you can't just bring the kitchen sink of random cargo pkgs with you :-)
<orbea>
python might have some bootstrapping issues for linux, but I wouldn't have thought rust would be better in that regard
<riteo>
it's not like not making the M1 GPU driver in rust won't result in rust in linux
<qyliss>
Python is much easier to bootstrap but I don't think that's really a driving force in the conversation
<riteo>
yeah I agree
<daniels>
riteo: as javierm noted above, there are a billion reasons other than safety for Rust
ManMower has joined #dri-devel
Guest222 has quit [Ping timeout: 480 seconds]
<riteo>
daniels: wait what other reasons
<riteo>
I only read the memory bugs thing
<riteo>
gimme a sec
<alyssa>
12:25 <danvet> plan in years for those bikesheds, if you want to be realistic
<alyssa>
honestly this is the big fear for me
<riteo>
how found it
<riteo>
<javierm> mripard: and also the error handling. That's one of the best things about rust IMO, people focus mostly on the memory ownership but algebraic types and the match pattern is awesome
<riteo>
this one
<alyssa>
ADTs are great yes
<riteo>
don't know anything about these, so I can't say anything good or bad under this regard
Net147 has joined #dri-devel
Net147_ has quit [Read error: Connection reset by peer]
<orbea>
regarding rust error handling, spending half an hour looking for the error when rust lists it as "warning:" is not fun.
<alyssa>
emersion: I do think your concerns here are valid ... touching /C++/ in mesa is always fun. I'm honestly nervous what Rusticl will mean for Gallium API migrations (the sort that happen on a regular basis with mareko around driving our draw overhead to 0)
<lina>
riteo: That solves the multi-versioning problem, but unfortunately it doesn't help with memory safety and dealing with general complexity...
tjmercier has quit [Remote host closed the connection]
<lina>
alyssa: ^ this too
<riteo>
lina: what general complexity? I thought that the main issue were versioned structs
<riteo>
I don't know anything about syntatic sugar or whatnot that it added so I can't really comment in a meaningful way about it
<Frogging101>
alyssa: And that circles back to the bus factor issue. If there aren't enough rust experts to maintain it then it will rot.
<Frogging101>
danvet said much on this topic, can search back up if you want to read it
<gawin>
returning to beginning: I think many people just wanted to say that lina is probably gonna be early adopter and it isn't most pleasant experience
<lina>
riteo: I have 2200+ lines of *struct definitions* for AGX, and that's not all of them. For one version. And most of the fields are still unk_##.
<riteo>
still, my opinion boils down to what I said before: I'm not against it if I'll still be able to compile linux with gcc in the long term
<lina>
That's with no duplication, it's 2200+ lines of entropy
<riteo>
lina: I see
<riteo>
I can't imagine though how rust syntax additions (which I don't know) might help with this, but I trust you on that regard
<riteo>
if the rust on linux initiative manages to take all the bad bits out of rust I'm all for it tbh
<lina>
The rest of the prototype Python driver is 2000+ lines, and that's only for minimal functionality, and of course Python is going to be more compact than C or Rust, and mostly gets to ignore memory allocation issues, and is of course single threaded (and single client).
<alyssa>
My gut feeling is that the happy path will end up being a "leaf" Rust module for firmware marshalling used /within/ the AGX driver advertising a C API, and then the part of the driver facing the rest of the kernel is C so we can kick the DRM bindings can down the road.
<lina>
Those are sloccount numbers, excluding whitespace/etc
<riteo>
and a big project like lina's is one of the only chances we have in the near term to really test the feasil
<riteo>
feasibility of such idea*
<alyssa>
which neatly avoids the concerns raised by emersion and danvet around DRM API migrations and common code across drivers
<alyssa>
and aoids danvet's concerns around years of bikeshedding for non-DRM driver stuff
<riteo>
alyssa: that sounds like a really nice idea actually to avoid a lot of preparatory work, in terms of M1 GPU support
<emersion>
actually that sounds like a pretty reasonable idea, alyssa
<riteo>
but I guess that if rust is really requested that it'll eventually spill into the rest of the core codebase
<lina>
alyssa: The Rust for Linux folks kind of didn't like that approach, and it doesn't help any other DRM drivers which might want to use Rust in the future, which doesn't help danvet's concerns about single users...
<alyssa>
It's "suboptimal" in a global sense but it gets most of the benefits without most of the drawbacks
<emersion>
and when rust a more well-established, we can talk about pure rust drivers
<lina>
I still plan to mix in C to some extent, but I'm not sure "don't bind any of DRM" is really the way to go here
<emersion>
more well-established in the kernel, that is
<alyssa>
lina: I don't really care what the RfL folks like if they haven't written a GPU driver before
<lina>
But I'm the one writing this driver...
* lina
would kind of hope her opinion matters a bit? ^^;;
<riteo>
lina: I think alyssa meant that they can't judge you for something they've never done before
<alyssa>
lina: and I trust your judgement and am hoping whatever path you choose will work out for you
<alyssa>
lina: I trust your judgement far more than the peanut gallery's ;)
<daniels>
^^
<lina>
My judgement right now is... neither way. I think I'm going to keep some parts in C for now (e.g. mm), and bind some parts of DRM, and see how that goes.
<riteo>
well I guess that ignoring any arguments you're the one handling all of this and thus it is your absolute right to do it the way you feel most confortable with
<riteo>
we all trust you in a way
<lina>
There's also a chunk where it's academic whether C or Rust is used, but I'm leaning towards Rust just to force me to learn how to deal with things, which I think is a valid reason.
<lina>
(e.g. the actual driver entrypoint stuff)
<Frogging101>
I see this as an experiment and I wish you good luck. The debate you met here is probably some of the most friendly you will meet along the way.
<riteo>
it has also the advantage of really testing the RoL approach, which is really something IMO
<daniels>
lina: 'try it, see what happens, use that experience to come up with a more clear answer' is a far better approach than 'strong opinions with zero rationale', yeah ...
<riteo>
Frogging101: same thing, I'm all in for experimentation as long as it isn't harmful for anyone, the experimentor included
<alyssa>
Frogging101: smashing indictment of the kernel community
<lina>
^^;;
<riteo>
wait I didn't read the debate part
<Frogging101>
alyssa: Heh. It's not an indictment but rather that I *know* there will be more resistance uphill
<Frogging101>
Justified or not
<riteo>
yeah rust's extremely polarizing for its reasons, I agree that this place's surprisingly friendly
<lina>
Will there though? RfL is already on the way, unless someone tries to block it last minute, it sounds like this story is pretty localized to DRM at this point...
<lina>
I'm certainly not going to be taking on the RfL fight myself ^^;
<lina>
But I hope using it for something big and scary helps push it along
<Frogging101>
It's a big project, there's always going to be unexpected hurdles. It's good to be prepared for the unexpected
<riteo>
lina: It'll sure confirm lots of things about its feasibility and more
<riteo>
that's why I actually appreciate someone making an huge project around this than the opposite
<riteo>
test it real bad!
<Frogging101>
The kernel development community is really conservative and they have good reasons for it. I don't criticize them for that
<lina>
I'm going to be honest, the amount of Rust for Linux code right now is a bit underwhelming (at least what has been submitted), so something like this is probably sorely needed. There are still lots of missing bindings, e.g. people are still working on PCIe drivers in Rust.
<lina>
The good news is that AGX conveniently has just about zero dependencies on anything but DRM and its interfaces.
<alyssa>
...and the worst case is that we ship the Rust driver to M1 users downstream and while they're enjoying 3D, we rewrite in C and end up with a tried and true Rusty design that gets merged upstream and that's... totally fine?
<alyssa>
so no reason not to try the Rust approach now?
<lina>
No IRQs, no regulators, no clocks, no resets, no fancy PM, no nothing. Just RTKit, which has a simple interface that is easy to bind (and is even used in a trivial way by AGX), and basic mmu and DRM stuff on top.
<lina>
alyssa: Exactly, I mentioned this earlier. Even just having the Rust driver working, with the compiler checking that the memory semantics are correct, would mean a 1:1 rewrite in C has a much better chance of not being broken.
<riteo>
alyssa: yup, there's literally no downsides on going the rust route
<alyssa>
dive in the deep end
<alyssa>
geronimo!
<lina>
If that happens though, as I mentioned, I need multiple-compilation. I can deal with writing this in C, but I am not going to maintain two dozen copies of the same code...
<riteo>
The options are two: a) the rust approach isn't accepted for whatever reason or fails for whatever reason and we all learn lots of good things in the meantime
<alyssa>
lina: :100:
<riteo>
b) the rust approach works, it gets integrated and everything's fine
<riteo>
either one of them is great!
silmathoron has joined #dri-devel
<Frogging101>
it's an experiment, like I said
<riteo>
Frogging101: yeah
<mareko>
alyssa: I think I can mostly handle refactoring ~20 drivers in C due to gallium changes, I don't think I'll be able to do that in multiple languages
<riteo>
this argument was already put on the table before
<orbea>
i'm only concerned it gets widely adopted regardless of how well it does or doesn't work the way firefox adopted it.
<riteo>
orbea: it's kinda harder in the kernel's case IMO
<riteo>
you gotta have a reason to build experience for something so alien to rust rn
<riteo>
to C*
<riteo>
it's literally easier to learn C if you don't know it already than to learn rust for a kernel developer
<orbea>
i do indeed it works out for the best :)
<orbea>
*hope it works out
<riteo>
same thing. In the end i'll be supporting anything productive that comes out of these experiments as anything can be improved or even rewritten in the worst case
<riteo>
all arguments are done for the sake of argumenting, not for hating on anyone doing such huge projects like lina
rsripada_ has quit []
<mareko>
alyssa: I don't think Rust allows some of the machine-level nastyness like we do in u_threaded_context, like reinterpreted memory and safe non-atomic unlocked multithreaded access that looks non-deterministic, but has a fixed set of defined outcomes where all outcomes are acceptable
rsripada has joined #dri-devel
<karolherbst>
mareko: it sure does
<alyssa>
mareko: Is that a plus or a minus? :P
<karolherbst>
if you want to do the same crappyness C allows you to do, you can always do that in rust as well
<riteo>
alyssa: I agree, I can't tell :p
<mareko>
alyssa: that depends on the writer
<karolherbst>
also.. atomics aren't really about deterministic behavior, just _sane_ behavior where you won't see the upper 16 bits updated, only the lower ones, e.g.
<karolherbst>
so I am questionable if what we have in gallium is even correct if you describe it that way
<karolherbst>
*questioning
<silmathoron>
hi there, I'm encoutering a mesa-related issue [1] on the Librem 5 and I wanted to know if I should open an issue on the mesa gitlab (or if it's already an known problem) and if there is additional relevant information I should include there. [1]: https://gitlab.com/mobian1/issues/-/issues/453
<karolherbst>
not sure why rust shouldn't allow undeterministic order of things to happen... even safe rust that is
<karolherbst>
lina: +1 for a driver written in rust :P
<karolherbst>
it's possible, the question is _how painful_ it will be
<mareko>
you can question all you want, but generally, all architectures are atomic at some aligned granularity, like 4B elements at minimum and 128B elements at maximum, and the atomicity as we view it is really just about cache communication
<Ristovski>
silmathoron: I'd say go for it
<silmathoron>
Ristovski OK, thanks!
<karolherbst>
lina: anyway, from my experience, people are more relaxed if you have the code to show that there are no concerns to have
<lina>
Well, I wanted to make sure the reaction from the maintainers wasn't "we aren't taking Rust, you're wasting your time" first ^^;;
<karolherbst>
mareko: sure, but then again.. why shouldn't that be possible in rust?
ybogdano has joined #dri-devel
<mareko>
I suppose it's possible to do anything in some unsafe block
<karolherbst>
rust is on the same level as C, it just tries very hard to prevent you from doing stupid things
<lina>
Also, if anyone wants to go a really deep rabbit hole... there's actually a problem I have that Rust can't solve right now, and neither can C. I need to be able to read/write from GPU-mapped structures, which *should* be considered untrusted (because we'd like to treat the GPU firmware as untrusted), but without incurring the overhead of outright using volatile or atomics for everything.
<karolherbst>
worst case, you write stuff in C
<karolherbst>
calling C functions in Rust comes without costs
<karolherbst>
and vice versa
<lina>
In other words, I need a memory access mode that basically says "the compiler optimizations will never yield undefined behavior under concurrent access by an untrusted party"
<lina>
If I understood it correctly, something like that or close to that exists in LLVM right now, but it is not exposed in Rust
<lina>
(Note: obviously all of this only applies to bag-of-bits type structures where all bit patterns are valid, which is the case with my structs)
<karolherbst>
lina: you have pointer of structs to mmio memory?
<lina>
Not MMIO, shared memory
<karolherbst>
ahh
<karolherbst>
shared between the firmware and the host I guess?
<lina>
Yes
<karolherbst>
mhhhh
<karolherbst>
I suspect you want to use volatile for that though :/
<lina>
That's too big a hammer, it would affect performance :(
<karolherbst>
or simply do a copy at defined points
<lina>
For now I'm just going to shove this problem under the carpet, because I'm pretty sure ~every driver mutating DMA structures has the same problem anyway under an evil-device threat model. It's one of those things that just about nobody is thinking about... but we should start thinking about it.
<karolherbst>
so if you start to use the data, just take a snapshot
<lina>
Copy doesn't work, because some structures are shared and need to be mutable by both sides.
<karolherbst>
well.. copy the result back then
<lina>
I mean I can't copy over the GPU-owned bits
<karolherbst>
mhhh... right...
<karolherbst>
annoying
<lina>
Yeah, it's a pretty hard problem, and *largely* theoretical since in practice it would be rare for the compiler to emit code that would be exploitable under this threat model, but the possibility is there...
<karolherbst>
maybe rusts Cow could help?
<ajax>
orbea: you know i've worked on fedora for my day job for greater than one decade, right?
<lina>
Another thing that makes dealing with this right now moot is that Apple's firmware has full page table access anyway, and is not hardened enough to trust it with that.
<lina>
But I *think* Apple plan to improve that, given what they tried to do so far.
<ajax>
i am _somewhat_ familiar with what a distro needs.
<karolherbst>
well...
<karolherbst>
I doubt it, and even then... with nvidia we have the same situation :(
<lina>
So in the future we might be able to say "the firmware privilege separation is solid enough that we can trust the page table code, but not the rest of it, so treating the firmware structures as untrusted is worthwhile"
<lina>
But that day is not today
<karolherbst>
yeah.. shared data with the firmware sucks somehow...
<lina>
Nevermind 2000+ lines of struct defines that change every version...
<karolherbst>
and I suspect you can't do a clear cut and make that memory not shared?
<karolherbst>
yeah... same here
<lina>
For some structures yes, but it's not practical to put structs in their own pages and map/unmap every time in a real driver, it's too expensive.
<karolherbst>
but I suspect if you don't want to trust the firmware, only a clean isolation of the data would actually be the only sane solution here
<lina>
You end up needing to alloc/free structs from pools that are always mapped on both sides
<karolherbst>
mhh
<lina>
Though I'm thinking of having a mode that does that anyway, for debugging purposes...
<karolherbst>
I'd write the "slow" code first, then come up with good ideas on how to improve that
<karolherbst>
and if that's like 0.01% of a perf difference, don't bother?
<lina>
Well, the "fast" code already exists, it's dma_pool ^^
<karolherbst>
we end up quite often think something is a perf problem, until somebody benchmarks it and sees: well.. it's not a hot path so it doesn't matter
<lina>
Either way I'm going to abstract out the whole object allocation/management stuff (same as I did in Python), so it'll be easy to swap out different implementations.
<karolherbst>
yeah.. probably a good idea
<lina>
One trick I do in Python is I alloc all structs in their own page(s), aligned to the end of the page, with a guard page after that.
<karolherbst>
but I guess in Rust it would be easy to have a wrapper around shared sturcts, which tracks what fields got updated and only writes that back in a "defined" way.. like if it's a counter, the difference will be added or something
<karolherbst>
dunno
<lina>
That way if the firmware thinks a struct is larger than I think it is, it crashes and the crash dump tells me what struct it was trying to read (I have a decoder for that).
<karolherbst>
ahh, that sounds useful
<lina>
Not sure if I'll implement that in the Rust driver, since it's mostly for reverse engineering (the Python code is staying, for several reasons - it will continue to be the research platform for new firmwares/GPUs)
<lina>
But it's a neat trick!
lynxeye has quit [Quit: Leaving.]
<karolherbst>
yeah
<karolherbst>
we have the advantage, that nvidia released their driver as open source, so we can at least check what structs are used...
<karolherbst>
still....
<lina>
Isn't that driver half just a shim around their blob driver, now running on the GPU?
<karolherbst>
we did similar stuff in valgrind-mmt where we tracked size of ioctls structs
<lina>
I figured not much of that would be useful for nouveau...
<karolherbst>
lina: sure, but it's still firmware and it's still shared data
MajorBiscuit has joined #dri-devel
<lina>
Fair!
<lina>
And I guess you know the m1n1 hypervisor tracer thing that marcan wrote was inspired by Nouveau ^^
<karolherbst>
anyway, I fully support any initiative to write a kernel driver in rust :D but I suspect it's more painful than what I did with rusticl
<karolherbst>
lina: not under this name I think
Major_Biscuit has quit [Ping timeout: 480 seconds]
<karolherbst>
but if I'd have to guess, it's similar to mmiotrace?
mclasen has quit [Remote host closed the connection]
<karolherbst>
ore closer to mmt?
* karolherbst
wishes somebody would write a new mmiotrace
<lina>
karolherbst: It's a thin hypervisor which can run macOS as a guest (the real macOS kernel, not the VM special edition one), and trace mmio, with all that being driven by Python on a host
<lina>
I ended up writing some pretty deep GPU tracing, that goes all the way to firmware structure decoding
<karolherbst>
okay, then it's essentially mmiotrace :)
<lina>
It can also run Linux, so it's handy for debugging ^^
<karolherbst>
ahh, cool
<lina>
It was originally meant for MMIO tracing, but I coaxed it into tracing arbitrary memory... so now I can have it literally trace read/write to/from every page the kernel maps to the GPU
jewins has joined #dri-devel
<karolherbst>
lina: anyway.. where is the discussion about using rust drivers in the kernel? and why wouldn't you be allowed to use drm stuff?
<lina>
Which is neat because I get things like struct dumps with lists of when each field was read or written by the CPU, with an op sequence number
<lina>
It was here, see backlog...
<karolherbst>
ahh...
<karolherbst>
lina: ehh.. just ignore them, they are in bad cop mode :P
<karolherbst>
if the rule is "if I have to touch rust code when updating APIs" it's useless to even use rust
<karolherbst>
honestly
<karolherbst>
that's a dumb rule
<danvet>
alyssa, lina yeah some more leave-y stuff might be a good way to start sneaking in rust
<karolherbst>
if that's the common ground we want to settle on, then you can just don't use rust
<danvet>
I was also thinking of maybe edid parser or things like that
<danvet>
lina, read*() and write*() are generally for poking device stuff (well registers but it's kinda all the same)
<karolherbst>
I suspect people will use bindgen to wrap internal C APIs
<karolherbst>
because anything else is nuts
<danvet>
and drivers do generally trust that the hw is not evil
<lina>
The thing is I'm trying to write a new driver... so I kind of need to decide whether to go all in on it now or not.
<karolherbst>
lina: all in
<danvet>
now read/write*() are a lot bigger since they have barriers, but also you do need those generally
<lina>
Drivers trusting that the hw is not evil is... not ideal. It kind of defeats the purpose of things like IOMMUs...
<karolherbst>
if somebody doesn't want to get rust in, they will always find random reasons why something is bad
<karolherbst>
it's a long term project
<lina>
But I'm talking about shared memory, not MMIO (read*/write* are for MMIO)
<karolherbst>
and long term, rust drivers _will_ use internal APIs with bindgen
<karolherbst>
and changing APIs _will_ require touching rust code
<karolherbst>
that's just the way it will be
<lina>
The equivalent for shared memory would be volatile, but what I'd like to have is a smaller hammer than that, for performance.
<danvet>
lina, well at that point you need to sprinkle a ton of writel/readl() all over it
<danvet>
maybe you can get away with READ_ONCE or WRITE_ONCE, but probably not (they're just volatile underneath, more or less)
<karolherbst>
yeah.. the kernel already has some internal wrappers around MMIO read/writes and I suspect even in rust you'd need to use them :/
<danvet>
yeah
<lina>
Yes, Rust has its own MMIO stuff already
<karolherbst>
sure
<karolherbst>
but the kernel version will use the kernel APIs internally
<karolherbst>
or so I hope
<lina>
I'm not talking about that, the AGX driver... doesn't need to do any MMIO at all.
<danvet>
paulmck has written a large series about how the lk memory model could be mapped to rust
<danvet>
and for better or worse for a lot of things the answer was "who knows"
<karolherbst>
anyway... the plan was to implement part of rusts stdlib on top of internal kernel APIs
<danvet>
the issue is that lkmm is not C memory model
<lina>
karolherbst: I meant the Rust-for-Linux stuff has MMIO wrappers already as far as I know
<karolherbst>
yeah.. I suspect so
<lina>
But either way... funny enough, I won't need them ^^
<lina>
AGX is funny hardware
<karolherbst>
those details should all be hiddin inside the stdlib impl
<lina>
And I'm 3 layers above MMIO before even starting to write the driver
<karolherbst>
uhh.. interesting
<lina>
(I actually only need MMIO for one thing, reading GPU fault addresses. That's it.)
<danvet>
so ... are there rust bindings for these agx things?
<karolherbst>
anyway... I am sure we should have the discussion about rust drivers will target the DRM api
<karolherbst>
and that people have to cope with rust
<karolherbst>
there is no other sane way of doing this honestly
<lina>
danvet: I will write Rust bindings for RTKit, which is the existing layer of code that the AGX firmware builds on top of (already upstream too)
<karolherbst>
if people refuse, we shouldn't do rust at all
<karolherbst>
just use bindgen?!?
<lina>
I mean, abstractions
<danvet>
karolherbst, yeah long term that's where it needs to go or it doesn't make sense
<karolherbst>
also
<lina>
Sorry, I keep using those terms interchangeably when they're not
<karolherbst>
there isn't such a thing like "rust bindings"
<danvet>
and that also means the helpers/core api need to be rustified a lot
<karolherbst>
rust can call C functions directly
<karolherbst>
and vice versa
<lina>
Yes, when I say bindings what I mean is abstractions
<karolherbst>
what bindgen does is some magic so it's not horrible
<karolherbst>
but there is no code generated
<lina>
safe or at least eventually-made-safe Rust abstractions for raw C APIs
<danvet>
yeah if all we do is write C in rust it's a bit pointless :-)
<karolherbst>
or well.. no "wrapper/binding" code
<karolherbst>
danvet: that as well, but what I mean is, rust code can call the DRM API _as_is_ without the need of any wrapping or bindings
<lina>
(FWIW, the RfL folks' plan is to forbid that by policy)
<danvet>
karolherbst, yeah but that's kinda the boring part
<lina>
(i.e. force people to write abstractions to avoid defeating the point)
<karolherbst>
true
<karolherbst>
but it's the first step regardless
<danvet>
the real fun is when you want to roll out adt and proper interfaces that leverage the borrow checker and all that
<karolherbst>
ehh
<karolherbst>
sure
<lina>
But yes, I'm sure I'm going to be having a mix of direct calls and abstractions initially
<danvet>
and you can hand-roll these semantics in C, but since it's hand-rolled it's going to be a bit a mess in translations
<karolherbst>
then you might want to start implementing a DRM Rust API using the C stuff
<Frogging101>
I wonder if there are any performance penalties to the indirection
<lina>
karolherbst: That's what I mean when I said DRM bindings
<karolherbst>
and just use the rust api and you have some glue code translation rust concepts to C
<karolherbst>
okay
<lina>
Writing a Rust API for DRM components using the C stuff
<karolherbst>
yeah..
<danvet>
for kms it's totally irrelevant, we don't even really optimize the C stuff :-)
<Frogging101>
I'm sure someone already brought that up when rfl proposed it though
<lina>
The RfL stuff already has a lot of such abstractions/APIs
<karolherbst>
anyway.. that's something I suspect will happen automatically anyway
<karolherbst>
as I did for gallium in rusticl
<karolherbst>
and I wouldn't worry too much about that
<lina>
Yeah
<lina>
Really, all I wanted to get out of today is finding out if people hate the idea or not ^^
<lina>
Tomorrow I actually start writing code
<karolherbst>
at this point it's more of an issue if people go into "I don't want to have to touch rust code at all" mode and basically prevent people from doing anything substantial
<karolherbst>
lina: I love the idea :P
<Frogging101>
I've bikeshedded yes, but I don't hate it.
<karolherbst>
but I suspect that's not a big surprise
<lina>
^^
<lina>
Well, I know you're a fan ^^
<karolherbst>
Frogging101: well.. we want to get it right rather sooner than later, so bikeshedding will happen. And sometimes people have to accept certain things, but if there are too many "not wanting to touch rust code" people out there, it becomes an issue
<karolherbst>
no idea why anybody would do that, because C is apparently a bad language, but here we are
<karolherbst>
s/apparently/obviously/
<lina>
(Also, the news cycles about this are already funny... and I haven't even started yet...)
<karolherbst>
yeah...
<karolherbst>
well...
<karolherbst>
phoronix is very jumpy on things which gets many clicks :P
* karolherbst
should just upstream rusticl and get official CL 3.0 conformance"
<lina>
They seem to find out about *everything* ^^;;
<mripard>
but somehow they missed the powervr driver
<karolherbst>
lina: I send out a patch to enable _one_version_ of ampere, literaly a 15 loc patch, single digit hours later: phoronix article
<karolherbst>
:D
<lina>
Ha.
<lina>
Wow.
<karolherbst>
lina: lol.. there is a second article about that GA103 enablement, simply because it was accepted as a fix to linux 6.0... :D
<karolherbst>
honestly....
<karolherbst>
*sigh* oh well
<Frogging101>
karolherbst: I would suggest not using the "C is a bad language" argument. It gets people's backs up. Rust has a PR problem because many of its proponents write as if it is simply a given that other languages are bad and Rust is the answer. Regardless of whether one believes this, it is not a productive introduction
<karolherbst>
Frogging101: just stating facts
<riteo>
re phoronix: yeah, it's funny to guess the number of comments by reading the title
<karolherbst>
people have to wake up from their dream land
<karolherbst>
I can't take people serious who say that C is a perfectly fine language
<riteo>
as soon as a few keywords are present the number of comments jumps to two digits, I should make a graph just for fun
<Frogging101>
"C is a bad language" is an opinion, not a fact
<riteo>
karolherbst: it depends on what you have to do
<javierm>
Frogging101: in the flip side, starting an argument with "one can write safe code in C" doesn't help either since experience has shown that's just not true
<karolherbst>
Frogging101: that's just like your opinion
<ajax>
okay but it's a correct opinion
<riteo>
for people in the groups I follow, who try to make the smallest thing possible, C is perfectly fine, although hare wants to improve the situation further
<karolherbst>
riteo: no, C is terrible
<riteo>
that's a bit dogmatic, there are issues in rust too
<karolherbst>
sure, but why does rust having issues make C not terrible? doesn't make sense
<Frogging101>
It turns the discussion from technical merit into dogma and absolutism
<ajax>
like, C has its place, it's the least bad tool for the job for many jobs.
<riteo>
I'm not saying that rust is terrible
<karolherbst>
yeah, C has its place, and that's fine
<riteo>
I'm saying that its implementation/ecosystem is pretty terrible, but it got its own big merits
<karolherbst>
but saying C isn't terrible is ignoring why C is bad
<ajax>
but any language that you can't point to at least one spot and say "this is terrible", is a language you've not seriously used.
<ajax>
and C has a _lot_ of those spots
<riteo>
C has issues, but bad implies that it's unusable, which is IMO not true
<karolherbst>
ajax: exactly
<karolherbst>
ignoring this basically means, you never looked beyond C and have not fucking clue what's possible
<karolherbst>
if all you did was C, of course it looks perfectly fine
<karolherbst>
but...
<karolherbst>
sorry to have to break it to you, C is terrible, and that's not even an opinion
<riteo>
again, C has a shitton of issues, the biggest that I know of is UB
<ajax>
if you're more interested in your emotional attachment to a language than to the reality that _all_ programming is an absolute impossible miracle and we're all wile e. coyote running off the cliff trying not to look down... well, that's a choice you canmake.
<karolherbst>
riteo: terrible things are usuable, that's not a contradiction
<riteo>
C isn't unusable bruh
<ajax>
also terrible but usable: cars. mcdonalds. democracy.
<karolherbst>
this doesn't make C not terrible
<riteo>
oh sorry, I read that other message wrong
* DragoonAethis
opens a 3rd popcorn bag
<karolherbst>
gas is also terrible thing to use, but hell does it work well :P
<lina>
The thing is, a huge portion of the anti-Rust folks use arguments along the lines of "you can write good, correct C code"... but, empirically, nobody really can (and I say this as a longtime C user...)
<lina>
So you're left to conclude that the language is the problem, there's no real way around it...
<karolherbst>
lina: correct
<riteo>
i'd argue that in big projects it's impossible
<riteo>
but in smaller utilities it's perfectly possible
<riteo>
still, I'm open for better solutions than C
<riteo>
I'm not a C evangelist, I'm perfectly open to experimentation. I'm just against calling it "terrible"
<lina>
Sure, you can write correct C in small doses, but once complexity starts to creep in...
<karolherbst>
riteo: yeah.. rust e.g. :P
<ajax>
lina: the contortions required for that (writing consistently good C), in my experience, are essentially writing your own little real-language runtime in every project
<riteo>
karolherbst: rust in the current state isn't a good alternative either
<ajax>
or picking your favorite one from like glib or nspr
<Frogging101>
You are framing the issue as an objective truth, and anyone who disagrees must have something wrong with them. That is bad. Don't do that.
<karolherbst>
riteo: why not?
<javierm>
C is terrible for writing safe code. I'm surprised that's up to debate
<riteo>
again, it's got a lot of problems regarding its ecosystem mostly, most of them covered by that drewdevault article
<ajax>
at which point... what is it winning you, to use C
<karolherbst>
riteo: what speficially?
<riteo>
once the cargo culting ends, a spec is made, the abi is stable and I can not use rustc I'll prefer it more
<riteo>
which isn't impossible at all
<karolherbst>
huh?
<karolherbst>
the API is stable...
<Frogging101>
I was actually hoping that the religious phase of this argument wouldn't come out today, but here we are
<riteo>
karolherbst: I meant ABI
MajorBiscuit has quit [Ping timeout: 480 seconds]
<riteo>
not API
<karolherbst>
why isn't the ABI stable?
<riteo>
dunno, you're looking kinda aggressive to my eyes
<lina>
(RfL still use nightly, for what it's worth, but they are ticking off the nightly features required slowly)
<riteo>
karolherbst: I must admit that I haven't experienced this myself, but I read that it's pretty hard to interoperate software compiled by different rustc versions
<riteo>
but really, chill off dude
<riteo>
I'm not going against either rust or C
Redfoxmoon has joined #dri-devel
<qyliss>
that's correct
<qyliss>
but Rust can export functions using the C ABI
<karolherbst>
riteo: yeah... I suspect that mixing different binaries compiled from different rustc sounds like a viable problem
<qyliss>
and presumably none of this is a concern for the kernel anyway
silmathoron has quit [Ping timeout: 480 seconds]
<riteo>
I know about both language's weaknesses and I'm not shilling either
<Frogging101>
We had a bunch of reasonable discussion earlier but now we're back to "naysayers just can't see the truth" type of stuff
<karolherbst>
qyliss: the funciton ABI is stable though
<karolherbst>
but structs might change
<lina>
Also, isn't kernel code supposed to be compiled with a consistent compiler version anyway? I couldn've sworn that was part of the module versioning... So this seems like a bit of a moot point.
<karolherbst>
well.. it's not stable as "being spec", but it also doesn't change
<javierm>
lina: indeed
<qyliss>
karolherbst: oh, the Rust function ABI is stable? I didn't know that.
<karolherbst>
well.. it doesn't change
<riteo>
lina: in the kernel context surely, I'm talking in general
<javierm>
riteo: but we are discussing here in the context of the kernel
<karolherbst>
but I doubt it's "stable" as in "will never change"
<riteo>
that's why I'm pretty ok with rust in the kernel if they take all the bad bits off
<riteo>
javierm: I know, it was with karolherbst that I made the discussion became a bit too general, sorry
<orbea>
it would be a lot of work to fix all the infrastructural problems
<karolherbst>
but well.. if a stable ABI is a must, why do peopel use C++? :P
<orbea>
i.e. cargo
<orbea>
but if someone manages that would be great
<karolherbst>
well.. we don't in the kernel, so that's a different problem
<riteo>
karolherbst: dunno, never experienced ABI issues with C++ but I never worked a lot with it either
<karolherbst>
orbea: you don't have to use cargo though
<qyliss>
it's very difficult not to
<Frogging101>
orbea: cargo is forbidden in the kernel, so hopefully that cements a need for cargoless usage
<karolherbst>
riteo: yeah, because if using the same compiler it's stable
<karolherbst>
but somer compilers allow you to use different ABIs
<karolherbst>
ICC e.g.
<orbea>
Frogging101: good to know that, hopefully that is right
<Frogging101>
orbea: yes, it was mentioned earlier
<karolherbst>
if using with gcc compiler binaries you have to tell icc, that you target gcc compiled binaries
<lina>
Haven't there been more than a couple C++ ABI flag days in Linux land? I remember some really messy things...
<riteo>
I don't know if that's my impression but there's a bit of heat in here
<karolherbst>
comes from the topic I suspect
<riteo>
we talked about rust before and it wasn't that heated either
<karolherbst>
or me.. :P
<heat>
yo
<Frogging101>
It doesn't have to. Avoid making dogmatic statements and you keep the temperature down.
<danvet>
karolherbst, lina btw after a bit more pondering I'm not sure whether doing a leave thing within a driver makes sense
<Frogging101>
That's what I was saying before
<karolherbst>
:(
<danvet>
that way we just have proliferation of rust abstraction things, and that feels bad
<karolherbst>
yeah, I know you are right, but C is still terrible
<riteo>
again, I've never used rust but heard a lot of its issues, that's why I'm not criticizing the syntax or other hands down things
<karolherbst>
I think I am just sad about not all people seeing this "obvious thing" :P
<riteo>
you're again being dogmatic
<danvet>
so driver level for the handover (like gallium in mesa in a way, just the other side)
<lina>
Frogging101: I think it's fair to point out C's problems though, it's objectively a language that just about nobody can write correct complex code in...
<karolherbst>
riteo: I was being ironic this time
<riteo>
oh ok, sorry
<karolherbst>
comes with IRC
<riteo>
lina: yeah sure
<javierm>
Frogging101, riteo: I think is hard to not get emotional after spending too many hours chasing memory issues on Linux :)
<karolherbst>
anyway.. assume that I am half ironic about most things
<danvet>
also I still think the best way here would be to have a 2nd rust driver for different hw, since generally after the 2-3rd or so user you have a pretty good chance of ending up with non-shitty interfaces
<javierm>
so I think karolherbst is being more pragmatic than dogmatic in this regard
<riteo>
javierm: don't talk about me with memory issues, I just fixed one right here, mesa side, that made our CI fail
<Frogging101>
it's fair to point out its problems but not to carry that statement into "and that's why everyone has to agree that rust must replace it, or they're being wilfully blind to C's shortcomings"
<riteo>
now it'll take wayyyyy too much time to propagate, or I hope not
<danvet>
also why do we seem to have a discussion about C being a complete dumpster fire
<danvet>
I'm typing blog posts on this in all areas after all :-)
<orbea>
lina: some would certainly disagree with that strongly, but true it does allow someone to shoot themselves in the foot.
<javierm>
danvet: precisely my point, I thought that was a given :)
<lina>
danvet: Right, that's the same thing the RfL folks said, so my plan is to write global DRM bindings for the things I use, at least the parts that interact with Rust. I might still have some C bits that implement real things talking directly to DRM APIs, but they wouldn't be mere shims for Rust to call into.
<karolherbst>
anyway.. doing a real project in rust is a better way of learning about rust pros/cons than reading blog posts by people never having seriously used rust
<karolherbst>
sure.. in theory there are a lot of issues
<karolherbst>
but what if they practically simply don't matter?
<danvet>
javierm, yeah for me the only questions is can we get enough critical mass behind rust so it doesn't have a bad bus factor, doesn't hold up necessary refactors in the subsystem and we don't end up with interfaces worse than what we have now in C
<javierm>
danvet: agreed on those concerns
<karolherbst>
I am sure if I would have a long discussion about implementing OpenCL in rust I'd have a lot of people saying "ugh... pls don't? there are those issues with rust: ..." ;)
<danvet>
which sounds like how is that possible, but given what I've seen when drivers reinvent locking, I really don't have a lower bar anymore for what drivers can do when left to their own devices
<karolherbst>
but I wanted to learn rust regardless, soo...
<karolherbst>
no point in asking
<orbea>
karolherbst: my main point earlier was to try building rust yourself to enjoy the whole expeerience :P
<karolherbst>
lol
<karolherbst>
"ahh that's why you got there"
<karolherbst>
had the same thing with OpenCL
<karolherbst>
"ahh that's why clover did it this way"
<lina>
danvet: For what it's worth, I've had my fair share of thinking about locking and memory models... I'm not going to claim I'll get it right on the first try, but at least I'm aware of the pitfalls. ^^
<danvet>
karolherbst, yeah there's enough good stuff in rust which has been very well proven in tons of other language (which are unsuitable for kernels for other reasons) that there's really not much discussions there imo
<lina>
And I did read your article, it's really good!
fahien has quit [Quit: fahien]
<orbea>
not everyone agrees, but its a common theme with distros that rust causes a lot of headaches :)
<karolherbst>
yeah...
<karolherbst>
it doens't fit the distributions model of packaging very well
<lina>
And I will *definitely* have questions about how, specifically, the DRM APIs interact with concurrency and locking (because that will be part of writing correct Rust abstractions)
<karolherbst>
question is: do distributions have to change, or rust
<danvet>
karolherbst, also since you've built rusticl you maybe doing the 2nd drm rust driver would be rather perfect I think ...
<danvet>
*hint, hint*
<karolherbst>
:D
<qyliss>
Well, Rust fits fine. Cargo doesn't.
<danvet>
:-P
<karolherbst>
_LOL_
<karolherbst>
let me first write a new compiler for nouveau
<karolherbst>
....
<danvet>
karolherbst, maybe not nouveau, that's a bit too big for an easy start
<orbea>
yea, cargo is the main hurdle i this regard
<karolherbst>
:D
<orbea>
*in
<karolherbst>
lina: yeah... that stuff is annoying
<karolherbst>
what usually helped me in rusticl is to have a mental model about what is Send and what is Sync and write the abstrations in this way
<karolherbst>
and what is even shareable or what isn't
<riteo>
uhhh lil ot: btw I added the 'Cc: mesa-stable' tag in my MR commit on suggestion of someone, could I do that or does that need previous approval?
<lina>
Yeah, I still need to wrap my head around those and Rust's concurrency model in general...
<karolherbst>
also understanding what &mut references are is a huge help
<karolherbst>
lina: after you understand &mut it's all easy
<lina>
Yeah, I think those I figured out. It's less about mutability and more of a shared-vs-exclusive thing, in my mind.
<karolherbst>
basically
<karolherbst>
that's why you can change Atomics without mut
<lina>
Yup, and the inner mutability pattern
<karolherbst>
if the operation is an atomic change, there is no need for &mut
<danvet>
lina, so on concurrency I think we should be fine-ish
<danvet>
at least I'm pushing very hard for simple locking that should fit into the borrow checker model
gouchi has joined #dri-devel
<karolherbst>
well...
<danvet>
and all the lkmm stuff can be dealt with by using existing drm C functions
<karolherbst>
normally you put protected data behind a Mutex<> in rust
<lina>
I'm thinking, specifically, about making sure I understand e.g. what API functions are reentrant, or aren't, etc.
<karolherbst>
and then it can be changed without an exclusive reference
<lina>
The kernel C API documentation in general tends to be very hit and miss on concurrency issues
<lina>
I'm not sure if DRM is better here...
<karolherbst>
any kind of locking won't match well with Rust
<danvet>
lina, yeah we don't document that in the functions
<karolherbst>
and that's one major point of pain
<danvet>
what I recommend is to document the locking model on the structures
<danvet>
and enforce it in the functions with lockdep annotations
<lina>
Sounds like I have a bunch of DRM reverse engineering ahead of me...
<danvet>
but ime also trying to document it in functions just means the docs are inconsistent and outdated
<karolherbst>
danvet: I am wondering if it makes sense to even move data protected by one lock into a struct
<karolherbst>
so you have simple lock <-> struct mappings
<karolherbst>
not lock <-> list of fields....
<lina>
Well, to build safe rust abstractions you *effectively* have to document this, in code
<karolherbst>
and then it gets easier to map that into rust
<danvet>
karolherbst, that's why that's the most preferred model in my hierarchy for locking patterns :-)
<karolherbst>
if you take a ref to that struct, you can have your own MutexGuard doing the locking
<karolherbst>
and then the rust code becomes quite trivial
<danvet>
karolherbst, well in many cases the C code will do the mutex stuff, or at least the actual locking
<danvet>
e.g. kms atomic get_state functions
<karolherbst>
sure
<danvet>
the fun stuff there is about enforcing context
<danvet>
e.g. with atomic there's atomic_check and atomic_commit
<karolherbst>
but that's not my point really. In rust you take a ref to protected data by locking it. Otherwise you can't touch it
<danvet>
and the locking rules are fundamentally different
<karolherbst>
if you generate bindings you can just mutate that struct
<danvet>
so would be nice to enforce in rust that you don't mix them up (which driver folks just love to do)
<karolherbst>
so what you want is a wrapper which is like Rusts Mutex around those C structs being protected
<danvet>
yeah
<danvet>
also perhaps a bunch of them and split the rust struct up
<lina>
(I also don't have a super good image for how much locking performance matters in DRM/GPU stuff, but my intuition would be that O(n) for single-to-two-digit mutex ops per submission ioctl isn't a huge deal?)
<danvet>
if you have fields which are protected by special locks
<danvet>
lina, for kms it just doesn't
<lina>
Yeah, I'm thinking render
<lina>
For KMS obviously none of this matters
<lina>
Remember, I'm not doing KMS
<danvet>
for command submission generally fixing your uapi and big desing matters so much more than any locking micro-opt
<karolherbst>
danvet: sure
<danvet>
e.g. if the per-obj lock sucks in your cs ioctl the fix is not to make that faster
<danvet>
but switch over to pre-bound model where you just don't do per-obj anything in the fastpath
<lina>
Right, that makes sense
<karolherbst>
bad APIs not bad code causes bad perf :P
<danvet>
the nice thing with drm render is that the uapi is always up for complete do-over for performance work
<danvet>
since it's not the real application uapi
<lina>
Either way, it's probably fine to do it the simple, lockful way first, and then start worrying about pre-binding optimizations, right?
<danvet>
karolherbst, yup
<karolherbst>
lina: heh.. say "lockless algorithms" and danvet will complain to your for hours, why that's a falacy :P
<danvet>
lina, tbh if you have enough gpu pagetables I'd do pre-bound directly
<danvet>
it's what vk wants
<danvet>
karolherbst, nah I'll just put you on the ban list
<karolherbst>
lol
* danvet
taking no prisoners on this topic
<danvet>
like on this one, airlied is actually the nice maintainer
<lina>
You mean contexts? That's actually a lot of what I wanted to talk about, and yes my plan is to cache those with some kind of LRU thing. I actually need LRU behavior in more than one place...
<danvet>
I've looked waaaaayyyyyy too deep into this abyss
<danvet>
lina, look at the i915 vm_bind rfc for what we plan to do for intel
* karolherbst
is surprsied to have gotten CLs events right tbh
<danvet>
which is pretty much what bnieuwenhuizen has built for amdgpu (minus the old uapi in both cases)
<danvet>
which is imo what we should build a nice driver toolkit for and just force everyone to do it like that
<lina>
AGX can do 63 contexts (page tables), 128 events (think active submitted commands, but I *think* I can get away with sharing some of these? Also each 3D command takes 2), and 256 buffer managers (stuff for managing tiling buffers for a context) simultaneously.
<danvet>
if they have the gpu ctx/pagetable hw ofc that's needed
<karolherbst>
riteo: normally it's part of the review process
<lina>
danvet: thanks, will do!
<karolherbst>
riteo: so if you want to nominate patches for stable on an MR, people have to be aware so they can comment on that
<lina>
danvet: I promise not to cook up any lockless algorithms myself ^^;;
<riteo>
karolherbst: oh, I see
<riteo>
should I remove it now or just write it as a comment?
<danvet>
lina, well if you use rust, my understanding is that you just can't
<riteo>
I wrote it in a thread in the MR that I did that since someone proposed it
<danvet>
or at least because of the lkmm, you need to build them in C and wrap them in rust
<lina>
You can certainly build whatever crazy lockless thing you want in unsafe {} in Rust
<karolherbst>
riteo: you can also always create an MR against a stable branch to pick commits from main. But normally if everybody is aware that you want to get stuff into stable, it's fine
aravind has quit [Ping timeout: 480 seconds]
<danvet>
lina, well the trouble is that the linux kernel doesn't really operate under the C memory model
<danvet>
so whatever funky stuff rust compiles in there, might fail in odd ways
<riteo>
karolherbst: all right, I'll just make sure that it's visible then
<lina>
I'll have to check, but I think the RfL project has Rust bindings for lkmm atomics?
<danvet>
was at least my take away from the paulmck blog series that went through all this
<riteo>
karolherbst: oh and thanks!
aravind has joined #dri-devel
<lina>
Either way, I don't plan on using them unless needed for some firmware thing...
<karolherbst>
np
<danvet>
anything that goes beyoned plain locks you have to build in C and then somehow wrap it in a way that from rust's pov it looks like totally normal locking
<danvet>
which in some cases I think is going to be very hard, because the C constructs rely on retry loops and your code being idempotent enough for that to not result in tears
<karolherbst>
well.. more like exclusive ownership, but same thing :P
<lina>
I'll have to check what RfL did for mutexes, but they surely must have a solution for this already
<danvet>
yeah mutexes and all that should be totally fine
<javierm>
danvet: I wonder if for rust might make sense to start rewriting one of the tiny drm drivers that don't have a complex locking scheme
<danvet>
javierm, trouble is that tinydrm has even more helpers than plain kms
<karolherbst>
javierm: I would say that doing what lina tries is perfect because you get the full experience
<danvet>
and I'm not sure whether you want to redo the tiny helpers in rust (so that they're neater)
<javierm>
danvet: right
<javierm>
karolherbst: that's true
<karolherbst>
no point knowing if rust works well for something "trivial"
<ajax>
can we please all stop saying "helper" when we mean, like, "base class method"
<lina>
Ah, they just wrapped the kernel's mutexes/etc in the same API as the native Rust ones I think
<danvet>
or wrap the tiny helpers again in rust and kinda end up with multiple c<->rust layers that nest in stupid ways
<karolherbst>
something something
<lina>
so you just import the RfL version instead of the std version and that's that
<danvet>
ajax, it's a linux kernel pattern, and it's not just base class method
<ajax>
it's a stupid word to use is my point
<ajax>
"thing doer"
<ajax>
"assister"
<ajax>
come _on_
<karolherbst>
"code"
<ajax>
if taking the word out removes no meaning, take it out
<danvet>
ajax, yeah outside of the kernel I agree, but within the kernel there's an entire pile of lwn articles
<danvet>
ajax, also the usual way to do the base class method is template implementations
<danvet>
which is exactly _not_ what the helper patter is about
<lina>
(meanwhile Rust has no classes...)
<karolherbst>
well... rust has something "close" enough
<lina>
Yes ^^
<karolherbst>
though it is quite limiting sometimes
<danvet>
if one of the code pattern books would have a good name for what goes for "helper library pattern" in the kernel, I'd use that
<danvet>
but I'm not aware of one
<karolherbst>
let's agree to call it "helper" :P
<danvet>
yeah it's shit, but the best shit we have
<riteo>
well, it has been real fun talking with y'all, but I gotta go do my stuff with godot now that the leak is (not yet officially) plugged
<danvet>
the name I mean
<riteo>
byeeeeeeeeee!
<ajax>
i'll call it something else that's six letters long and sed it out before i send the patch, i guess
<karolherbst>
riteo: have fun
riteo has quit [Quit: epic rust moment]
<lina>
I should get some sleep, it's 2AM here and tomorrow I'm probably going to spend all day starting to work on this...
<karolherbst>
lina: start now, so you can get to bed early
<danvet>
ajax, so what do you call "pile of implementations and parts thereof that might or might not be useful for building your own driver, but not generally a complete framework as in a base class implementation"
<danvet>
since generally there's multiple, often exclusive, and good helpers are rather pick&choose kind of deals
<danvet>
"helps build your driver" is the best I can come up with really
<danvet>
"*can help build your driver" to be more precise
<ajax>
i would call them "common code" and i wouldn't put the word "common" in the name. it's implied by leading with the word "drm". if you need something else you change the prefix to "i915".
<ajax>
literally s/helper_//g
<danvet>
well how do you differentiate the helpers then from the core functions drivers have to use?
<lina>
karolherbst: start time is 3PM, that's already scheduled ^^
<danvet>
sprinkle core or mandatory over all of them?
<karolherbst>
lina: then have a good night!
<danvet>
javierm, karolherbst ^^ I also wonder how much reusing the C helpers really makes sense for rust, in some cases building completely new ones might be better
<ajax>
there's this new thing called comments
<ajax>
if they're mandatory then the driver will crash if you don't use them so whatever.
<karolherbst>
danvet: the thing is.. there is no way to use static inlines
<karolherbst>
so sometimes you don't have any good choice
<danvet>
karolherbst, we don't have that much of them anyway
<danvet>
ajax, in practice people copypaste an existing driver
<ajax>
if you really insist you say "direct rendering - mandatory" and "direct rendering - utility".
<ajax>
dru_whatever
<danvet>
and so need to get from reading the code which parts they can ditch and replace with their own
<danvet>
and for which they need to keep it
<ajax>
or dont-reinvent-me / maybe-reinvent-me
<danvet>
and generally people only read comments when things blow up
<karolherbst>
danvet: but yeah... I did some new ones for list stuff in rusticl...
<karolherbst>
it always depends on how easy it is to wrap certain stuff
<danvet>
which they wont if you just build an abstraction layer to fight the optional abstraction layer because you didn't realize the optional abstraction layer is optional
<karolherbst>
first priority should always be "how to make this easy to use in rust"
<karolherbst>
and go from there
<danvet>
ajax, yeah dru_ vs mru_ might be good, but somehow we ended up with [nothing] and helper_
<danvet>
*drm vs mrm or whatevr
<ajax>
okay but also...
<ajax>
"helper" to me does not at all imply "you can swap this out if you need to"
<ajax>
it implies "this does a complicated thing you probably don't want to reinvent"
<danvet>
emphasis on probably
<danvet>
if the complicated thing it does just doesn't fit or you don't need it, then just don't use it
<ajax>
and i guess more to the point: if there _is_ this kind of polymorphism at some point, maybe use a vtable.
<danvet>
well that's the other part of the helper patter
<danvet>
you get the vtable directly for the driver, and generally there's no default implementation
<danvet>
so that you force drivers to build a fitting one, from their own and the provided pieces
<danvet>
and sometimes there's a few defaults that cover 90% or so
aravind has quit [Ping timeout: 480 seconds]
* ajax
stops pushing the boulder uphill
<danvet>
ajax, I mean I agree with you on the name being silly, but it also is a very specific concept for drivers
<ajax>
i'm never fixing linux, i just wish we didn't let it infect mesa
<danvet>
and now just "have some vfuncs and base class methods and you're good"
<ajax>
i really don't think it's that special, but my opinion is not going to matter here
<danvet>
yeah for an upstream project with multiple drivers it's pretty normal
<danvet>
the trouble is explaining this to random hw vendor driver teams
<danvet>
because on their own, they always screw this up
<danvet>
you can pretty much tell from this alone whether a driver is by a new team or one with upstream experience in some project (whether mesa or kernel or whatever really doesn't matter)
<javierm>
danvet: yeah. I was half joking on that. Since you also have some utility functions or whatever is called
<danvet>
and then your back to "library" which I guess is about as useful as "helper"
<danvet>
I mean if a very clever name would fix the problem of having to explain this to vendors someone smarter than me would have solved this by now I'm sure ...
frieder has quit [Remote host closed the connection]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<bl4ckb0ne>
what is going on under the hood for texture -> eglimage and eglimage -> texture? is it the same texture referenced twice or a copy?
<bl4ckb0ne>
im trying to fix GL_EXT_EGL_image_storage by adding cubemap supports and only the first face gets carried over
kts has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Remote host closed the connection]
silmathoron has joined #dri-devel
elongbug_ has quit [Read error: Connection reset by peer]
silmathoron has quit []
fahien has joined #dri-devel
<daniels>
ajax: if Mesa's taught us anything, it's that the correct replacement for 'helper' is 'dri2'. or, if you want it to be six letters long, 'dridri'
fahien has quit []
<karolherbst>
hot take from today: let's move away form IRC, so we don't have to discuss the "C is bad" topic anymore and just assume it's bad :P
<zmike>
IRR?
<Sachiel>
Internet Relay Rambling
<karolherbst>
but honestly.. now that we replaced cgit with gitlab, what do we replace IRC with?
<karolherbst>
sounds like the next big project
<Frogging101>
nothing
<Frogging101>
(I don't know if you're being serious)
<karolherbst>
this time I am
<Frogging101>
we don't replace it with anything because the alternatives are terrible
<Sachiel>
matrix I guess? Maybe when 95% of the people are using that and the irc bridge is unreadable, the rest of us will finally care enough to switch
<karolherbst>
just because IRC is the most terrible option, we can still replace it by something _less_ terrible
<karolherbst>
IRC doens't even support emojis in nicknames, it's literally trash software
soreau has joined #dri-devel
<Frogging101>
so are you still being serious, or
<karolherbst>
I want to be called "🐧karolherbst🐧"
<karolherbst>
Frogging101: 100% seirous
<Frogging101>
I don't believe you.
<karolherbst>
emojis are the best thing ever happened to Unicode
<karolherbst>
I mean it
<Frogging101>
No more trolling sir
<karolherbst>
I am dead serious on this
<karolherbst>
(Also having fun that apparently you don't beleive me)
<karolherbst>
🐧🐧🐧🐧🐧
<Sachiel>
💩
<karolherbst>
my army of unicode 🐧🐧🐧🐧🐧🐧 will haunt everybody saying that unicode emojis are 💩
<Rayyan>
noot noot
<Frogging101>
🤫
<Sachiel>
🙃
<karolherbst>
sometimes this channel is 🔥
<Rayyan>
lots of dri development happening in this channel
<emersion>
replace IRC with IRC-but-not-OFTC
<bl4ckb0ne>
^
<Rayyan>
^
<karolherbst>
but anyway, we need to replace IRC as this becomes a problem especially for more younger developers, because they think we are just old farts not using discord or something :P
<emersion>
so the solution is to use discord…. ?
<karolherbst>
that goes a bit against open source, doesn't it?
<karolherbst>
but Rust is on discord... mhhh
<Rayyan>
define younger developers
jkrzyszt has quit [Ping timeout: 480 seconds]
<emersion>
_a bit_
<karolherbst>
Rayyan: younger than me
<danvet>
karolherbst, well I'd need a client that can do unicode emoj i and not suck at it ...
<danvet>
but yeah I'd so splatter them everywhere ...
<karolherbst>
:D
<karolherbst>
same
<Rayyan>
karolherbst: your age? (if you're comfortable with saying it obviously :P)
<alyssa>
karolherbst: does Matrix let you be 🐧karolherbst🐧
<karolherbst>
Rayyan: I leave it up to the reader :P
<karolherbst>
alyssa: I have no idea and if not, I'd file a bug
<danvet>
karolherbst, like ideally all the input fields across all my devices share the same favorite emoji and stuff
<Rayyan>
I imagine I'm probably younger than you lol
<karolherbst>
maybe
<Rayyan>
you old fart
<Frogging101>
Discord's an awful platform and I'd rather be thought of as "old" than use it to look "hip"
<karolherbst>
that makes others _really_ old farts
* danvet
older than X11
<Frogging101>
I'm 26
* karolherbst
younger than X11
<Rayyan>
/me is <18
<karolherbst>
Frogging101: yeah... I have no idea what's a good alternative here either
<karolherbst>
just it will become a problem at some point
<karolherbst>
or so I imagine
<Frogging101>
no, I don't think it will.
<emersion>
i'm still volunteering for setting up a fdo IRC bouncer btw
<emersion>
but daniels wasn't so hot about it
<karolherbst>
yeah.... I think the path will be, somebody tries something nice and we just roll with it
<karolherbst>
bridging isn't too bad these days I've heard
<karolherbst>
but we'll get to the point where people are 50% on IRC and 50% on discord (because rust and other projects or soemthing) and IRC becimes this relict "only used for fdo"
<karolherbst>
most new projects don't start with having an IRC channel
<Frogging101>
I don't care
<daniels>
my objection to those kinds of services is that we just don’t have the bandwidth to deal with the inevitable abuse
<bl4ckb0ne>
i start mine with irc channels
<karolherbst>
daniels: yeah... probably
<Frogging101>
This topic is just creating noise, as well
<daniels>
but I’m also not even really involved these days so take that as just another peanut-gallery comment
<alyssa>
I think we should all use XMPP
* alyssa
will show herself out
<emersion>
i should write up a formal proposal
<karolherbst>
uhhhh
<karolherbst>
alyssa: take that back
<alyssa>
dri-devel@conference.freedesktop.org
<daniels>
emersion: ++
<alyssa>
what's not to like
<karolherbst>
Frogging101: I am strictly against a "this is how we did it, and that's how we'll continue doing it" mentality
<karolherbst>
alyssa: I think the problem was that besides adium all XMPP clients were horrible
<Frogging101>
That isn't my mentality, so there's no conflict there
<karolherbst>
yeah.. just saying it
<pixelcluster>
I honestly think having Mesa/dri development on IRC has quite some upsides
<pixelcluster>
(as one who would probably qualify as "younger developer" :D)
<karolherbst>
like dealing with spam is somebody else problem? :P
<Frogging101>
It's more of a "Discord is bloated and walled garden trash, and IRC has a healthy FOSS ecosystem despite (or perhaps because of) its limited feature set" mentality
<karolherbst>
yeah....
<karolherbst>
that's a big pro for IRC atm
<karolherbst>
but I see this changing already
<karolherbst>
there will be the point were IRC will mostly consist of people being stuck in the past
<karolherbst>
will it be in 10 years? or 50 years?
<karolherbst>
who knows
<FLHerne>
karolherbst: eh, people have been predicting that since literally before I started using IRC
<emersion>
fwiw daniels, i've been maintaining a bouncer with 1k users for quite a while now, and with technologically advanced features such as… push notifications
<FLHerne>
since before I was born, probably :p
<karolherbst>
if FOSS were around when faxes were the only way of communicating, we'd still use Fax :P
<FLHerne>
IRC is old
<karolherbst>
FLHerne: well.. jsut that then there was really no alternative
<FLHerne>
the only real FOSS alternative is Matrix, but the client ecosystem still kind of sucks
<karolherbst>
yeah.. agreed
<FLHerne>
or at least it did last time I tried to find a good Matrix client which was last year sometime
<karolherbst>
it's more of a thing for in 5+ years or something I figure
<jenatali>
I'd jump on the bandwagon for ditching IRC if there's a vote that ends up happening. The lack of a sane way to manage accounts is probably the main reason that I'm the only one out of my team that hangs out here
<karolherbst>
FLHerne: but there are also web clients, which don't suck
* Sachiel
suggests MS Teams
<FLHerne>
karolherbst: web clients suck by definition
<Frogging101>
Sachiel: haha
<jenatali>
Not Teams... please
<karolherbst>
Sachiel: I humbly but firmly suggest you to leave
<FLHerne>
I have enough browser tabs already
<karolherbst>
:P
<emersion>
jenatali: by "manage accounts", do you mean register a new account and login, or something else?
<karolherbst>
but yeah... IRC has this "offline" issue, where being offline means, nobody can reach you
<Sachiel>
some would call that a feature
<FLHerne>
anyway, they all seem to have no idea of information density - my IRC channel list doesn't fit on my screen in plain small text, in Matrix web clients I've seen it would be like four pages long
<Rayyan>
bouncers exist :P
<jenatali>
I mean the fact that IRC is usually pseudo-anonymous, people have nicknames but no persistence, and the bolted-on account management via commands to a bot is... awkward at best
<FLHerne>
never mind scrollback of busy channels
<karolherbst>
Rayyan: yeah well...
<jenatali>
And the fact that messages go to the void if you're not authenticated is also confusing for people who aren't used to it
<emersion>
messages don't go to the void, they return an error
<karolherbst>
jenatali: I think nobody denies that IRC is a pile of hacks on a pile of hacks
<jenatali>
Especially when people would prefer to use a bouncer (like a Matrix bridge) which introduces even more hiccups for authentication
<FLHerne>
jenatali: tbh that's mostly just this channel, because of That Guy
<emersion>
karolherbst: it's not if you have a good server
<karolherbst>
please....
<jenatali>
emersion: Like I'm literally getting double messages from you right now :)
<FLHerne>
(the +q thing)
<Frogging101>
For some reason all the modern stuff, Element included, is allergic to plaintext search. All of them have search bars that for some reason will munge your search terms whether you use quotes or not
<emersion>
jenatali: the issue is the matrix bridge, i assume?
<jenatali>
Dunno, it's only you that's sending me doubles though
<karolherbst>
Frogging101: yeah........
<Frogging101>
I like that I can grep my IRC logs, even with regex if I want to
<emersion>
jenatali: the matrix bridge _really_ doesn't help
<karolherbst>
but that's more of a client thing and with more people on it, I suspect stuff like that will get sorted out eventually
<jenatali>
Yep, fair
<emersion>
it adds more bugs on top of the poor state of OFTC's server
<FLHerne>
Somewhat relevantly, just yesterday #openttd on here got a Discord bridge
<airlied>
danvet: what does a non kms rust driver need? ww mutexes, dma buf/fence
<airlied>
no vram on m1 eithe
<FLHerne>
the only problem is that it creates individual IRC users for each Discord client speaking, which requires a huge pool of IPs to not hit the OFTC client limit :p
<FLHerne>
luckily TrueBrain happened to have one handy
<karolherbst>
FLHerne: I thought that's what we got IPv6 for
<Frogging101>
sounds like they should ask for a limit exception
alyssa has quit [Quit: so long]
<FLHerne>
karolherbst: yeah, but OFTC views everything smaller than a /48 or something as a single IP because of ISPs handing out huge blocks
<karolherbst>
uhhh....
<danvet>
airlied, well we have a bunch of shmem helpers
<FLHerne>
maybe it was a /56
<karolherbst>
still terrible
<danvet>
airlied, scheduler maybe for sorting out dma_fence dependencies
<emersion>
FLHerne: you can ask them to add you to their rate limit exception list
<danvet>
airlied, and also I think sooner or later we want some vm/vma helpers so that people don't reinvent all possible ways to do that badly
<danvet>
airlied, I guess the bigger issue is that on the non-kms side the helpers are a lot less polished and there's still a lot to improve
<danvet>
I think kms settled a lot more
<FLHerne>
it is a /48, but with a higher limit of 50 connections per /48
<emersion>
i obtained a no-limit for my IP range
<FLHerne>
emersion: was discussed with dwfreed, so far it seems to work as-is so eh
<emersion>
alright
<airlied>
danvet: so nouveau in rust then :-)
<danvet>
I already tried to volunteer karolherbst, seemed reluctant
<danvet>
no idea why
<karolherbst>
:D
<karolherbst>
I am still busy with rusticl
<karolherbst>
let me get the CL 3.0 conformance first, then I might be up for something
ngcortes has joined #dri-devel
fab has joined #dri-devel
Haaninjo has joined #dri-devel
Votes78 has quit [Killed (NickServ (Too many failed password attempts.))]
Votes78 has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
danvet has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
DieuDIEU has joined #dri-devel
ybogdano has joined #dri-devel
DieuDIEU has quit []
<Lyude>
conflict hit on drm-tip, resolving
aswar002_ has quit []
aswar002 has joined #dri-devel
fab has joined #dri-devel
pi2 has quit [Remote host closed the connection]
pi2 has joined #dri-devel
<Lyude>
done
YuGiOhJCJ has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
<idr>
zmike: I'm testing a possible fix for 7070. It fixes that test case, but I want to make sure it doesn't ruin everything else.
sobkas has joined #dri-devel
<zmike>
idr: awesome!
warpme___ has joined #dri-devel
apinheiro has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
<sobkas>
but when I run eglinfo https://paste.debian.net/1250678/ I get problems, for example gnome-console is invisible, kitty works ok, and I'm getting libEGL warning: DRI2: failed to authenticate
<sobkas>
I'm using xrdp with xorgxrdp
stuart has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<jenatali>
sobkas: That output looks fine to me, it says Wayland's not available, neither is GBM, but it can connect to X
<sobkas>
I have problem that for example gnome-console is invisible, while for example kitty shows up
<sobkas>
when runing gnome-console I'm getting libEGL warning: DRI2: failed to authenticate
JohnnyonF has quit [Read error: Connection reset by peer]
<jenatali>
That's probably unrelated
<sobkas>
jenatali: is it side efect of using swrast?
<jenatali>
Yeah, there's no DRI2 driver in WSL
clararussell[m] has joined #dri-devel
dakr has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
heat has quit [Read error: No route to host]
heat has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
carlosstive[m] has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<dj-death>
is there a NIR pass that tries to lower derefs to temporaries into ssa values rather than load/store operations?
<dj-death>
like a store/load in a single block
<cwabbott>
dj-death: that would be lower_vars_to_ssa and copy_prop_vars which only works within a single block but can handle the presence of indirects/other types of variables than function_temp
<sobkas>
jenatali: so swrast in egl is normal?
<jenatali>
sobkas: GLOn12 for WSL is implemented as swrast, yes
<dj-death>
cwabbott: thanks alot!
<sobkas>
jenatali: I will update windows drivers and see if it helped, thanks.
<jekstrand>
idr: I dropped what I think is a more plausible explanation in the bug. Short version: NIR is fine. The test is doing exactly what it's supposed to do: detect Intel's out-of-spec discard behavior. We were passing it as a fluke before.
<jekstrand>
I suspect what we really want is for Zink to detect the appropriate features and stop using normal discard
<jekstrand>
For drivers which support VK_EXT_demote_to_helper_invocation, it should use OpTerminateInvocation and with the driconf option to switch to OpDemoteToHelperInvocation
<jekstrand>
zmike: ^^
Donaldbtc[m] has joined #dri-devel
heat has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
<zmike>
uhhhh
<zmike>
hm
heat has joined #dri-devel
<zmike>
seems like both maybe
<jekstrand>
Well, if Zink wants reproducable discard behavior, it should use demote/terminate
<zmike>
sure
<zmike>
but also the nir got mangled somehow
<jekstrand>
Nope, the NIR is fine
<zmike>
🤔
<jekstrand>
It's the fact that Intel's discard doesn't actually kill lanes like it's supposed to.
<zmike>
well I'm at the pub so this will have to wait for tomorrow's me
<jekstrand>
That's fair
<zmike>
better be
<Sachiel>
zmike: or you could propose this issue as a trivia question at the pub
<zmike>
I bet those are the same ones from the mold MR
<karolherbst>
might be...
<zmike>
whatever you did to the build system broke llvm
<karolherbst>
I am sure llvm is fine
<karolherbst>
so there are two things I did: update meson and rust
<karolherbst>
and the changes to the build system itsels is very small in that MR
<karolherbst>
let me update my branch and see if that changes anything
Donaldbtc[m] has quit [autokilled: This host violated network policy. Mail support@oftc.net if you feel this is in error. (2022-08-16 23:51:39)]
<idr>
jekstrand: I don't think the NIR is fine. Look at the diff I posted. It's clearly converting 'if (cond) { a = true; discard; } else { a = false; }' into 'if (cond) { discard; a = undef; } else { a = false; }'
<idr>
Not that both the order of the assignment and the discard change and, as a result, the RHS of the assignment changes.
<idr>
I don't think that's valid.
<zmike>
karolherbst: yeah some minor aspect of that causes it
<idr>
Looking at the for-loop below... I think this is code added by the GLSL compiler to prevent infinite loops due to the Intel behavior.
warpme___ has quit []
<jekstrand>
idr: I was mistake about what the test is doing but I don't think I'm totally off about what's going wrong.
<jekstrand>
idr: Look at the first NIR from hang version. It's clearly only setting @0 in the "don't discard" case and then using it to break the loop.
<jekstrand>
Which would be correct if Intel's discard actually killed lanes
<jekstrand>
So it's actually inside zink that things are going weird
<karolherbst>
zmike: I suspect the images are out of sync or something...