ChanServ changed the topic of #asahi-gpu to: Asahi Linux: porting Linux to Apple Silicon macs | GPU / 3D graphics stack black-box RE and development (NO binary reversing) | Keep things on topic | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-gpu
<lina>
And I've seen blit commands somewhere I think, though I haven't started reverse engineering them
<lina>
But it probably maps pretty closely to that Metal thing
<lina>
Oh, alyssa left :<
<Ella[m]>
lina: oh thanks, had a quick look at mvk and it uses this :)
<lina>
I figure working out the blit commands won't be too much work, but it's probably still worth pushing for common code that can do it using the 3D pipeline?
<lina>
Up to you userspace people, whenever anyone starts looking at the blit commands at the IOGPU layer I'll be happy to help work out the kernel side ^^
<tophevich[m]>
line: nice job on the python driver cleanup and wiki documentation on it
<tophevich[m]>
*lina
<lina>
Thanks! Still not quite there yet... I need to finish writing the 3D command walkthrough
<lina>
(What actually happened is I was working on it on a laptop away from home and I didn't have my worktree with the latest field names... oops.)
<lina>
But the version I pushed after that does have a lot of global s/// to make some names more reasonable, so now I can wrap up the wiki docs
MajorBiscuit has quit [Ping timeout: 480 seconds]
<lina>
tophevich[m]: I still have very little idea how to do lifecycle management properly, concurrency, barriers, all that... so if any of what I wrote so far rings any bells from the point of view of other GPUs please do tell! ^^
<lina>
For now I plan on doing that silly tight memory-polling trick to watch structures update during a render, and hopefully get a better picture of what happens.
MajorBiscuit has joined #asahi-gpu
<tophevich[m]>
It worked well so far :) Also I love how your logging turned out, such a nice job on coloring, naming, indenting/spacing of those. Puts many a debugger to shame :D
<lina>
Ahaha, thanks! I keep telling people that investing in tooling up front always pays off! ^^
<lina>
Now I just need a version of grep that ignores ANSI color sequences... wonder if anyone has written that yet or I should
<lina>
Also credit goes to phire for the initial "make Constructs proper classes/objects" idea, that really worked out nicely!
<lina>
(That grep thing is probably a perl one liner, to be honest...)
<tophevich[m]>
yea, and it shows that python is really a good tool for the job, does really give you quite a leg up on doing those kind of things
<lina>
Yeah, everyone always looks at m1n1 funny when they first hear about it... drivers in Python, what?!
MajorBiscuit has quit [Ping timeout: 480 seconds]
<lina>
But it's so much faster to prototype in than C... I'd much rather write almost the entire kernel driver in Python, make sure I understand it and the achitecture is solid... and then just convert to C(/Rust?) once. It's a lot easier to rewrite something you already understand.
<tophevich[m]>
From what I've seen, I'd wholeheartedly say go for it, it will also help you for next hardware, and the one after that
MajorBiscuit has joined #asahi-gpu
<tophevich[m]>
I also have a feeling that it being cursed and all might have some blessings in disguise, some edge-cases you might find out now that maybe with a driver on hardware might not show up so pronounced and obvious. (There is obviously a flip-side but, hey looking at the bright side here :D)
<chadmed>
when rust support drops into mainline, does it come with rust bindings for all the kernel interfaces or is that something that's up to early adopters to port/implement?
<chadmed>
im thinking it would be an enormous flex and achievement to have the first proper rust driver in the kernel, but the burden of having to bring DRM to Rust would be enormous
<chadmed>
yeah thats what i thought the state of play was like
<tophevich[m]>
without anything using the bindings, they would be stale from the get-go, no?
<chadmed>
well we want to get this upstreamed so spinning out a bespoke interface that no one else will ever use would preclude that immediately
<chadmed>
which means we either have to port DRM *sanely* to Rust or wait for someone else to do it and lose the first mover trophy :P
<tophevich[m]>
you'd have to be a bigger part of the effort than you most likely want to be
MajorBiscuit has joined #asahi-gpu
<chadmed>
i mean rusty drm will get there eventually and nothings stopping us from porting the driver to rust once that happens
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-gpu
MajorBiscuit has quit [Ping timeout: 480 seconds]
<lina>
chadmed: It's worth noting that DRM is two things, KMS and 3D
<lina>
KMS has a huge helper API surface, which would be very hairy to bind to Rust
<lina>
3D, maybe not quite as bad?
MajorBiscuit has joined #asahi-gpu
<lina>
I plan to spend some time looking at DRM drivers to figure out what the best plan is
<lina>
My current thinking is that if Rust lands, it might be a good reason to write *part* of the driver in Rust (e.g. the GPU structure management bits), even if the core driver that uses DRM APIs is written in C
<lina>
Nothing stops us from moving more of it to Rust over time, of course
<lina>
But I think there's also no real reason not to use Rust to some extent if it ends up helping out with the driver
<lina>
I'm particularly interested in API compatibility breaks. I wonder what M2 did there. Rust should make it a lot easier to write generic code that can be specialized for different firmware ABIs, with C that gets pretty hairy (see: DCP)
<_jannau_>
DCP is already pretty hairy to begin with, ignoring multiple supported versions
<lina>
Yes...
<zx2c4>
lina: i highly recommend _not_ writing the kernel driver in rust at this point in time
<zx2c4>
it's still not clear that that stuff will ever get merged
<zx2c4>
rust people are hopeful. jury is still very much out wrt kernel people
<_jannau_>
in the worst case we could add version specific Call/Callback tables and hope that the driver logic stays mostly the same
<zx2c4>
it's probably reasonable to do *userspace* stuff in rust -- whatever helper code you have there, mesa, shader compilers, etc. but the dm driver itself? much better off in C at this point in time
<zx2c4>
and very likely much better off for the foreseeable future too
<lina>
zx2c4: I'm not going to be starting on the driver until months from now most likely, by which point it should be merged if it will be
<zx2c4>
i would be entirely unsurprised if in a year from now, it's merged. actually, i'd be totally surprised if it were merged in a year from now.
<zx2c4>
but yea, sure, i guess when you sit down to write it you'll see what the state is
<lina>
I'm obviously not going to start writing a driver in a language that isn't actually supported at that time...
<zx2c4>
well, technically you could do that and intend to rely on gobs of out of tree stuff from the rust-on-linux people
<zx2c4>
anyway, i suppose this means we're in simpledrm world for quite some time longer
<lina>
We'll see :)
<lina>
But really, I could start cranking out a badly designed C driver tomorrow... it'd even render stuff, but it would need a ton of work going forward.
<lina>
I'd rather work on that in Python first.
<lina>
The UABI is also a problem, that's going to be unstable for months which means it cannot be upstreamed, and the more we nail that down with Python prototypes the better.
<_jannau_>
the dcp (kms driver) is hopefully less far out, certainly for our fork
<lina>
That yes
<zx2c4>
lina: oh, yea, i had in mind just the actual drm part, sans 3D, which indeed is tons of work. so i guess just the kms part
<zx2c4>
good to hear that's closer
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-gpu
<_jannau_>
I have a working driver for the main display out. main issues to be solved before upstreaming are: 1. support for firmware allocated iommu mappings, 2. dt-bindings for the display out
<_jannau_>
2. requires adding support usb-c display out since we need to figure out how to support multiple displays
<_jannau_>
exporting each dcp/dcpext as separate kms device would be to annoying to do
<sven>
and then we're back to the atcphy mess :<
<_jannau_>
so the solution will be to hanle each dcp as crtc but I'm unsure if the drm helpers can easily deal with crtc with separate IOMMUs
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-gpu
MajorBiscuit has quit [Ping timeout: 480 seconds]
nehsou^ has joined #asahi-gpu
nehsou^ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-gpu
nehsou^ has joined #asahi-gpu
nehsou^ has quit [Ping timeout: 480 seconds]
intoxx[m] has joined #asahi-gpu
MajorBiscuit has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #asahi-gpu
nehsou^ has joined #asahi-gpu
alyssa has joined #asahi-gpu
<alyssa>
-1 on being the first rust drm driver in the kernel
<alyssa>
that's not a trophy we want. we do want the "it works at all" trophy.
<alyssa>
we're a community backed reverse-engineered driver. getting it working upstream at all is enough of a flex.
<alyssa>
and even for a 3D-only driver it'd be a pile of bindings work to do acceptably
<lina>
It doesn't have to all be Rust or even have bindings... we don't know how much it makes sense to write in Rust yet
<lina>
Assuming Rust support makes it in before we start
<alyssa>
I guess
<alyssa>
I care more about getting stuff working upstream than making "neat" engineering decisions, IDK
<lina>
I care about the driver working properly, and if Rust helps us get there faster and with fewer bugs...
<lina>
You've seen the Python driver, the design has a lot of very object-oriented concepts going on at the firmware ABI level. It could a better fit for rust, especially managing the lifecycle of all those things...
<lina>
I'm not saying it's the right choice, but I'm saying I don't want to dismiss it from the get-go
<alyssa>
I guess so
<alyssa>
this is "old man [young girl] C programmer yells at cloud [newfangled language]" i admit :p
<alyssa>
OOP in C isn't that bad
<lina>
And besides, with the UABI to work out before it can go upstream, it's not like writing it in C would get us there quickly anyway... and all that time spent working out the UABI is also time to figure out Rust things (if, and only if, Rust support is already in by the time we start, of course)
<lina>
OOP C isn't that bad, but object lifetime management in C *is* bad.
<alyssa>
Finalizing the UABI doesn't block merging into asahilinux/linux and shipping to users ..
<lina>
The kernel does a terrible job at that in all the exceptional cases, just try yanking a Thunderbolt cable and seeing how many different NULL derefs you manage to hit...
<lina>
It doesn't, but nor does Rust if it's already upstream
<alyssa>
sure
<alyssa>
(Or more to the point, running userspace on bare metal Linux without drm-shim hacks)
<lina>
We're definitely not going to gate the driver on hopes and dreams of Rust getting upstreamed, that's a hard dependency for taking that path.
<lina>
Realistically though, I'm going to be off a couple weeks next month, and there is still work to be done figuring out how this thing works before I'm comfortable starting to hack on a real driver, especially a C driver (C is definitely more painful to refactor than Rust)
<lina>
So I would say mid august-september for a sensible timeline for actually starting to work on a real driver. And then, if I'm right about how I'm doing things, it should go very quickly since we'll understand this GPU enough.
<alyssa>
That's fair
chadmed_ has joined #asahi-gpu
<lina>
So then it depends on what state Rust is in by then, and how I feel about it.
<chadmed_>
alyssa: "flex" might have been a slightly too loaded word :P
<chadmed_>
i didnt mean that we should any% a rust driver just for the sake of it/bragging rights, that would of course be ill advised
<_jannau_>
merge window for 5.19++ should be closed by end of july
<chadmed_>
it would merely be cool if things did line up fortuitously so as to allow a high quality, upstreamable driver to be written in rust
<lina>
I'd also be open to starting work in C and then starting to sneak Rust in once it goes upstream, if that isn't ready in time.
os3 has joined #asahi-gpu
nehsou^ has quit [Remote host closed the connection]
nehsou^ has joined #asahi-gpu
nehsou^ has quit [Remote host closed the connection]
Gaspare has joined #asahi-gpu
Gaspare has quit [Quit: Gaspare]
alyssa has quit [Quit: leaving]
Gaspare has joined #asahi-gpu
zamadatix has joined #asahi-gpu
zamadatix has left #asahi-gpu [#asahi-gpu]
zamadatix has joined #asahi-gpu
zamadatix is now known as zamadatix[m]
MajorBiscuit has quit [Ping timeout: 480 seconds]
zamadatix[m] has quit [Quit: issued !quit command]
zamadatix[m] has joined #asahi-gpu
chadmed_ has quit [Ping timeout: 480 seconds]
chadmed_ has joined #asahi-gpu
chadmed_ has quit [Ping timeout: 480 seconds]
Gaspare has quit [Read error: Connection reset by peer]
chadmed_ has joined #asahi-gpu
chadmed_ has quit [Ping timeout: 480 seconds]
<Sobek[m]>
Isn’t rust in Linux getting merged in the next version ?
chadmed_ has joined #asahi-gpu
<Sobek[m]>
(I’ve read something suggesting that it is likely getting merged in 5.19 to be precise)
chadmed_ has quit [Ping timeout: 480 seconds]
dhromw^ has joined #asahi-gpu
chadmed_ has joined #asahi-gpu
chadmed_ has quit [Ping timeout: 480 seconds]
chadmed_ has joined #asahi-gpu
chadmed_ has quit [Ping timeout: 480 seconds]
chadmed_ has joined #asahi-gpu
MajorBiscuit has joined #asahi-gpu
Raqbit9 has joined #asahi-gpu
mort_2 has joined #asahi-gpu
chadmed_ has quit [Ping timeout: 480 seconds]
os has joined #asahi-gpu
FLHerne_ has joined #asahi-gpu
merry_ has joined #asahi-gpu
gruetze_ has joined #asahi-gpu
vup2 has joined #asahi-gpu
akemin-dayo has joined #asahi-gpu
kit_ty_kate2 has joined #asahi-gpu
pg12 has joined #asahi-gpu
Emantor has quit [reticulum.oftc.net liquid.oftc.net]
PhilippvK has quit [reticulum.oftc.net liquid.oftc.net]
CME has quit [reticulum.oftc.net liquid.oftc.net]
lookitssky[m] has quit [reticulum.oftc.net liquid.oftc.net]
os3 has quit [reticulum.oftc.net liquid.oftc.net]
PthariensFlame[m] has quit [reticulum.oftc.net liquid.oftc.net]
Raqbit9 is now known as Raqbit
FLHerne_ is now known as FLHerne
qdot has joined #asahi-gpu
gtk2 has joined #asahi-gpu
chadmed_ has joined #asahi-gpu
CME has joined #asahi-gpu
PhilippvK has joined #asahi-gpu
Emantor has joined #asahi-gpu
lookitssky[m] has joined #asahi-gpu
dottedmag has joined #asahi-gpu
ar has joined #asahi-gpu
twoscomplement0b[m] has joined #asahi-gpu
TellowKrinkle[m] has joined #asahi-gpu
tophevich[m] has joined #asahi-gpu
ExeciN[m] has joined #asahi-gpu
nilsi[m] has joined #asahi-gpu
IbrahimMAkrab[m] has joined #asahi-gpu
long[m] has joined #asahi-gpu
SuchirMishra[m] has joined #asahi-gpu
willow[m]1 has joined #asahi-gpu
bpalmer4[m] has joined #asahi-gpu
fridtjof[m] has joined #asahi-gpu
user1tt[m] has joined #asahi-gpu
nik875[m] has joined #asahi-gpu
metalgeardaner[m] has joined #asahi-gpu
konr-72[m] has joined #asahi-gpu
DanielHuisman[m] has joined #asahi-gpu
tt022[m] has joined #asahi-gpu
brstream[m] has joined #asahi-gpu
CristianMgheruan-Stanciu[m] has joined #asahi-gpu
silverocean[m] has joined #asahi-gpu
solv[m]1 has joined #asahi-gpu
eccli[m] has joined #asahi-gpu
M7ooooo[m] has joined #asahi-gpu
asie has joined #asahi-gpu
MarcinPajkowski[m] has joined #asahi-gpu
ognju[m] has joined #asahi-gpu
tmosey[m] has joined #asahi-gpu
Nilsson[m] has joined #asahi-gpu
M0x8FFshulkk[m] has joined #asahi-gpu
kedde[m] has joined #asahi-gpu
shawnliu[m] has joined #asahi-gpu
happy-dude[m] has joined #asahi-gpu
orlofj[m] has joined #asahi-gpu
luxio_39[m] has joined #asahi-gpu
arnidg[m] has joined #asahi-gpu
henje[m] has joined #asahi-gpu
JasonAntwi-Appah[m] has joined #asahi-gpu
YichaoYu[m] has joined #asahi-gpu
photogrant[m] has joined #asahi-gpu
dumistaken[m] has joined #asahi-gpu
unsui[m] has joined #asahi-gpu
swampertx[m] has joined #asahi-gpu
plantaintion3[m] has joined #asahi-gpu
EugeneChen[m] has joined #asahi-gpu
badlydrawnface[m] has joined #asahi-gpu
AdryzzOLEDEdition[m]1 has joined #asahi-gpu
petermlyon[m] has joined #asahi-gpu
PthariensFlame[m] has joined #asahi-gpu
misteraftermath[m] has joined #asahi-gpu
vivg[m] has joined #asahi-gpu
Felix[m]1 has joined #asahi-gpu
daelaam[m] has joined #asahi-gpu
Fl1tzi[m] has joined #asahi-gpu
Dcow[m] has joined #asahi-gpu
Thib[m]1 has joined #asahi-gpu
Augur[m] has joined #asahi-gpu
Name[m] has joined #asahi-gpu
alexanderwillner[m] has joined #asahi-gpu
alexandruchi[m] has joined #asahi-gpu
go4godvin has joined #asahi-gpu
FilipJeretina[m] has joined #asahi-gpu
aem64[m] has joined #asahi-gpu
will[m] has joined #asahi-gpu
meher1[m] has joined #asahi-gpu
booffo[m] has joined #asahi-gpu
domoarigatomrroboto[m] has joined #asahi-gpu
melijah[m] has joined #asahi-gpu
willow[m] has joined #asahi-gpu
f-fritz[m] has joined #asahi-gpu
M5Q[m] has joined #asahi-gpu
jcramerus[m] has joined #asahi-gpu
wollymilkcap[m] has joined #asahi-gpu
blassphemy[m] has joined #asahi-gpu
lazrfocus[m] has joined #asahi-gpu
latosca[m] has joined #asahi-gpu
RasmusEneman[m] has joined #asahi-gpu
kaygalle[m] has joined #asahi-gpu
fortelling[m] has joined #asahi-gpu
notyou[m] has joined #asahi-gpu
AndrewLee[m] has joined #asahi-gpu
AkihikoOdaki[m] has joined #asahi-gpu
probablykevin[m] has joined #asahi-gpu
simosbara[m] has joined #asahi-gpu
feta has joined #asahi-gpu
peerp[m] has joined #asahi-gpu
waytrue[m] has joined #asahi-gpu
matthewayers[m] has joined #asahi-gpu
retonlage[m] has joined #asahi-gpu
Dementor[m] has joined #asahi-gpu
daftfrog[m] has joined #asahi-gpu
borhanborhan[m] has joined #asahi-gpu
sepkov[m] has joined #asahi-gpu
danielgek[m] has joined #asahi-gpu
xiaoming[m] has joined #asahi-gpu
QusarNe8ula[m] has joined #asahi-gpu
Genbuchan[m] has joined #asahi-gpu
rethematrix[m] has joined #asahi-gpu
denden[m] has joined #asahi-gpu
pulpy_orange2[m] has joined #asahi-gpu
ryanhrob[m] has joined #asahi-gpu
Taro[m] has joined #asahi-gpu
shnert[m] has joined #asahi-gpu
eaxk[m] has joined #asahi-gpu
itsn0k[m] has joined #asahi-gpu
AdityaJS[m] has joined #asahi-gpu
WellHoney[m] has joined #asahi-gpu
ashtez[m] has joined #asahi-gpu
MajorBiscuit has quit [Ping timeout: 480 seconds]
dhromw^ has quit [Ping timeout: 480 seconds]
dhromw^ has joined #asahi-gpu
gruetze_ is now known as gruetzkopf
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-gpu
c10l has quit [Quit: Bye o/]
chadmed_ has quit [Ping timeout: 480 seconds]
c10l has joined #asahi-gpu
chadmed_ has joined #asahi-gpu
MajorBiscuit has joined #asahi-gpu
chadmed_ has quit [Ping timeout: 480 seconds]
chadmed_ has joined #asahi-gpu
MajorBiscuit has quit [Ping timeout: 480 seconds]
dhromw^ has quit [Read error: Connection reset by peer]