swaggie has quit [Remote host closed the connection]
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
c10l has quit [Read error: Connection reset by peer]
c10l has joined #asahi-dev
pjakobsson has joined #asahi-dev
pjakobsson_ has quit [Ping timeout: 480 seconds]
amarioguy has joined #asahi-dev
amarioguy has quit [Remote host closed the connection]
amarioguy has joined #asahi-dev
derzahl has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
swaggie has joined #asahi-dev
unixgeek has quit [Remote host closed the connection]
pjakobsson_ has joined #asahi-dev
WindowPain_ is now known as WindowPain
pjakobsson has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
___nick___ has quit [Ping timeout: 480 seconds]
swaggie has quit [Remote host closed the connection]
c10l has quit [Quit: Ping timeout (120 seconds)]
swaggie has joined #asahi-dev
c10l has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
swaggie has joined #asahi-dev
<marcan>
zzywysm: looks sane, and that reminds me I should send out the t600x bluetooth changes too (those are in the intersection of two things now already merged in)
<marcan>
(this is why I prefer to do DT changes via our tree, because then I don't have to wait for the upstream merge to get dependencies in and it avoids the merge conflicts)
c10l has quit [Quit: Ping timeout (120 seconds)]
<sven>
I think Bluetooth had to go through the bt tree because I introduced that generic BT controller binding and they was already at least one follow up commit based on that
<sven>
*there was
SSJ_GZ has joined #asahi-dev
c10l has joined #asahi-dev
gladiac has joined #asahi-dev
c10l has quit [Ping timeout: 480 seconds]
c10l has joined #asahi-dev
swaggie has quit [Remote host closed the connection]
swaggie has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
c10l has quit [Ping timeout: 480 seconds]
c10l has joined #asahi-dev
swaggie has joined #asahi-dev
karpouzi has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
<karpouzi>
the mac mini finally arrived
<karpouzi>
is it still true that the latest DP/TB3 branch is atcphc-20221130?
<sven>
fair warning, that subsystem is a bit strange
<sven>
but then again, so is everything USB related
<maz>
(understatement of 2022)
<karpouzi>
warning appreciated
mps has quit [Ping timeout: 480 seconds]
<sven>
maz: I didn't want to scare karpouzi away before they even started ;)
c10l has joined #asahi-dev
<sven>
karpouzi: heikki usually replies pretty quickly to emails and feel free to ask me here as well. I've already spent quite some time banging my head against usb and typec
<karpouzi>
ty! i am still in the 'setting up' phase with this kit, will ping when ready
bcrumb has joined #asahi-dev
<marcan>
maz: re TSO, how much pushback do you think I'll get for trying to get it added to prctl? :p
<maz>
marcan: gut feeling: at best, you'll get ignored. at worse, this will go down into a flame war around an effective fork of the whole userspace ABI... and all the variants in between.
<marcan>
uh... effective fork of the whole userspace ABI?
<maz>
the main issue is that SW that fails without TSO and works with it will simply always enable it instead of debugging the stuff.
<marcan>
this is intended for x86 emulators
<maz>
... and will be used by everyone because it will hide bugs.
<maz>
(see, we're getting there! ;-)
<marcan>
yeah okay, any better ideas besides crippling performance of x86 emulation? :p
<karpouzi>
quick question... if you're working with different versions of the kernel, ie different branches of the same linux git repo, is the best way to save build time... to have duplicate linux repos? or is there another technique
<marcan>
I get your point but I don't see how you could possibly do both
<ChaosPrincess>
if process.name == 'fex': enable_tso() :P
<karpouzi>
tso = timesharing option?
<sven>
karpouzi: ccache + fast-ish VM for building works for me
<karpouzi>
ah i guess i don't technically have to build it on the m1 oops
<karpouzi>
plenty of buildserver around, thanks for the reminder
<sven>
it's a good idea to build it on the M1 though because those machine make for a fast build machine ;)
<sven>
+s
<ChaosPrincess>
probably argue that tso support is coming to new arm64 anyway, just that apple uses a non-standard switch
<maz>
ChaosPrincess: you obviously have better information on the architecture than I do...
<maz>
the direction of travel so far is the exact opposite.
<marcan>
maz: so what you're saying is we should just enable it downstream and let the gamer voices eventually become loud enough to annoy upstream into finding a solution ;)
<maz>
marcan: I wonder if we can somehow make the TSO stuff a VM property instead of a per-process thing.
<marcan>
hm, what's the distinction exactly?
swaggie has quit [Ping timeout: 480 seconds]
<maz>
the distinction is that Linux itself doesn't need to know. the whole VM is TSO, end of story.
<null>
Enabling the IMP-DEF bit *within* the kernel for this goes against the very strong upstream policy that we do not do so, doesn't work in VMs and so on (because it'll trap to the hypervisor)
<null>
Likewise, so does advertising it
<marcan>
oh like kvm VMs?
<null>
yes
<karpouzi>
sven: actually, the m1 wasn't bad - built in ~15min
<ChaosPrincess>
maz: ok, i might have misremembered since i cant find it, but there is definitely that fujitsu arm that already has tso
<marcan>
null: IIRC you can actually control whether VMs trap to EL2 or not for this
<null>
or any hypervisor, since when running at EL1 we don't know the hypervisor
<maz>
ChaosPrincess: that's owing to its SPARC heritage. nobody forced them to build shit HW... ;-)
<null>
marcan: sure, I'm just trying to say that in general it doesn't work, and to make it work requires a lot more finesse than may be initially obvious, since you need to reliably inform both ends, etc
<ChaosPrincess>
hey, if the 3 sparc-lovers would have been itc, they would be very upset
<null>
... and the policy in general is simply "Do not expose IMP-DEF stuff to lower ELs"
bcrumb has quit [Quit: WeeChat 3.7.1]
<null>
(and likewise, lower ELs should not assume the presence of IMP-DEF stuff unless explicilty advertised (e.g. in DT for PMUs and such)
<marcan>
sure, but that seems like a somewhat orthogonal problem to support at EL2 for userspace purposes?
<null>
WIth neted virt it's not ;)
<marcan>
OTOH there is an argument that x86 emu folks should use VMs anyway to get 4K pages, which could also involve a VM-global TSO switch
<marcan>
but then with nested virt you have the same problem
<null>
I'm very much not keen on relaxing the policy, because it implies a very long tail of consequences, and we have no guarantee tthat a vendor won't completely change the thing in arbitrary ways in a future release, so we can't really commit to an ABI
<null>
... and the architecture is clearly going in a different direction, with special instructions rather than a mode
<marcan>
I don't have a particularly big horse in this race, but if FEX ends up being like twice as fast with TSO mode the end result is just going to be us supporting it downstream and ending up with the resulting API fork, because it's too much benefit to just leave on the table
<marcan>
and even if M4 or whatever ends up doing it a more "standard" way, I'm not keen on leaving earlier users screwed
<null>
I appreciate that argument, but that's "twice as fast, on specific hardware, using an IMP-DEF feature', and crap everywhere else
<marcan>
well, this hardware is also twice as fast as the competition already :)
<marcan>
don't blame me for every other vendor failing to deliver
<marcan>
I'm not a fan of IMP-DEF nonsense but I see why Apple did what they did here
<null>
I don't think it's leaving users screwed as such, and while I appreciate people want every ounce of performance they can get, I think this is setting ourselves up for a much larger set of problems going forwards
<null>
Not blaming you, I just want ot be clear here so it's not a surprise on the list
bcrumb has joined #asahi-dev
<marcan>
yeah, I'm just saying, if upstream doesn't want this to happen whatsoever, I don't see ourselves not doing it downstream if the benefits are significant
<marcan>
to be clear, my policy here isn't to implement all the Apple nonsense, kernel be damned
<marcan>
I have no intention of implementing AMX because that sounds like a giant pain, with more EL0 state and undocumented *instructions* and just no
<marcan>
but if there's a bit I can flip to make FEX not suck the calculus is different
<marcan>
the reality is we have a huge amount of hardware out there that could potentially benefit from this, and if that conflicts with kernel policy, that's kind of a problem
<marcan>
(mind you, this is all conditional on TSO actually mattering - it's entirely possible FEX could just use atomics everywhere and not lose too much, we'll find out once I put a knob for systemwide TSO in m1n1 so they can try both)
<marcan>
(if it's like 5% benefit for normal load/stores and TSO over normal mode and atomics, I don't care)
<null>
I do appreciate that argument, but on the flip side there are a bunch of such things that over vendors do that could arguably be similar, and the calulus for upstream isn't just "enablnig this one thing for this one vendor's HW"
<null>
I must really learn to type better
<maz>
(still using that funky split keyboard?)
<null>
Nah, I'm actually on an M1 macbook pro today; on the ergodox I'm a bit better
<marcan>
right, I think the issue here is how much benefit we get out of it
<marcan>
as I said, if it's 5%, whatever
<marcan>
but if it's "you can actually play x86 games at good performance on fanless laptops with better graphics than on macOS with three graphics translation layers, but only if Linux supports this one thing" then...
<marcan>
obviously we're some time away from that point
<marcan>
but we'll get there eventually
<marcan>
and so there might come a day, if things work out like that, where gaming on Macs ends up being conditional on Linux supporting that TSO bit
cylm_ has joined #asahi-dev
<sven>
did anyone test how much slower everything gets if we just enable TSO globally?
<marcan>
mind you, yeah I was just about to say that
<marcan>
because the short-term solution is almost certainly going to be a m1n1 option to enable TSO globally, and a /chosen/asahi,tso flag so userspace can know it's available
<marcan>
and then we'll find out exactly what we can do with it
bcrumb has quit [Read error: Connection reset by peer]
c10l has quit [Quit: Ping timeout (120 seconds)]
swaggie has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
c10l has joined #asahi-dev
bcrumb has joined #asahi-dev
<bcrumb>
i noticed someone posted an additional PR in asahi-scripts
karpouzi_ has joined #asahi-dev
Gaspare has joined #asahi-dev
c10l has quit [Quit: Ping timeout (120 seconds)]
karpouzi has quit [Ping timeout: 480 seconds]
karpouzi_ is now known as karpouzi
karpouzi has quit [Quit: leaving]
karpouzi has joined #asahi-dev
<karpouzi>
did anyone hear an update about the RNDIS kerfuffle
<karpouzi>
/msg NickServ SENDPASS karpouzi
<karpouzi>
uh whoops
<marcan>
karpouzi: that patch is not upstream, I think it was never merged
<karpouzi>
... weird!
<marcan>
I imagine some discussion happened offlist after the NACKs he got, or it just got stuck in limbo
jluthra has quit [Remote host closed the connection]
<sven>
smells like some "unfixable" 0-day that either isn't unfixable or actually isn't a bug
<karpouzi>
he's not, like, off his rocker or something
jluthra has joined #asahi-dev
<karpouzi>
makes sense to me.
bcrumb has quit [Ping timeout: 480 seconds]
Gaspare has quit [Quit: Gaspare]
karpouzi has left #asahi-dev [#asahi-dev]
iaguis has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
gladiac has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
<kettenis>
hey, how dare you to say bad words about SPARC when I'm not watching! ;)
<maz>
kettenis: I love SPARC. one of the first architectures I actually enjoyed playing with (well, sun4m -- I really didn't like the SW TLB on sun4c).
<maz>
kettenis: do you want to take this v490 from me? I also have a spare T1000 if you want!
<kettenis>
I certainly don't want the v490 and I have a t1k ;)
<maz>
crap. I need a victim.
<sven>
lol
MajorBiscuit has quit [Read error: Connection reset by peer]
swaggie has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
swaggie has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
swaggie has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
iaguis has quit [Quit: leaving]
swaggie has joined #asahi-dev
swaggie has quit [Ping timeout: 480 seconds]
<null>
maz: I forget, did you end up with my T1000 in the end? IIRC I still have the rails in the cupboard under my stairs
bcrumb has joined #asahi-dev
bcrumb has quit []
<maz>
null: yeah, I have two now. no need for rails though, the machines are piled 1.5m high. high density computing! ;-)
bcrumb has joined #asahi-dev
renatorabelo has joined #asahi-dev
bluetail has quit [Read error: Connection reset by peer]
bluetail has joined #asahi-dev
bluetail has quit [Read error: Connection reset by peer]
bluetail has joined #asahi-dev
Gaspare has joined #asahi-dev
bcrumb has quit [Quit: WeeChat 3.7.1]
bcrumb has joined #asahi-dev
bcrumb has quit [Quit: WeeChat 3.7.1]
Gaspare has quit [Quit: Gaspare]
bcrumb has joined #asahi-dev
bluetail has quit [Ping timeout: 480 seconds]
bcrumb has quit [Quit: WeeChat 3.7.1]
amarioguy has quit [Remote host closed the connection]
renato has joined #asahi-dev
amarioguy has joined #asahi-dev
renatorabelo has quit [Ping timeout: 480 seconds]
swaggie has joined #asahi-dev
bcrumb has joined #asahi-dev
<bcrumb>
it would be cool if someone could look @ those asahi-scripts PRs for me, they would make life much easier when upgrading to new kernel versions :D
<bcrumb>
obviously, when you guys have time, just mentioning
bcrumb has quit [Quit: WeeChat 3.7.1]
bcrumb has joined #asahi-dev
<bcrumb>
also i think the installer should notice whether the presets in mkinitcpio.d are x-ed out and then upgrade those, instead of writing new .presets
<bcrumb>
so, the whole Make process
<bcrumb>
also sorry, i don't know if this exactly only kernel talk or also stuff like this fits here
bcrumb has quit []
swaggie has quit [Remote host closed the connection]
swaggie has joined #asahi-dev
wCPO624365 has quit []
renatorabelo has joined #asahi-dev
javier_varez__ has joined #asahi-dev
zzywysm_ has joined #asahi-dev
nathanchance_ has joined #asahi-dev
jbowen_ has joined #asahi-dev
wCPO624365 has joined #asahi-dev
Method_ has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
zzywysm has quit [Read error: Connection reset by peer]
digicyc has quit [Remote host closed the connection]
javier_varez_ has quit [Ping timeout: 480 seconds]
javier_varez__ is now known as javier_varez_
digicyc has joined #asahi-dev
jbowen_ has quit []
jbowen_ has joined #asahi-dev
renato has quit [resistance.oftc.net larich.oftc.net]
Method has quit [resistance.oftc.net larich.oftc.net]
nathanchance has quit [resistance.oftc.net larich.oftc.net]
ids1024 has quit [resistance.oftc.net larich.oftc.net]
jbowen_ has quit [resistance.oftc.net larich.oftc.net]
jbowen_ has joined #asahi-dev
ids1024 has joined #asahi-dev
Method has joined #asahi-dev
renato has joined #asahi-dev
Method has quit [Ping timeout: 482 seconds]
renato has quit [Ping timeout: 482 seconds]
SSJ_GZ has quit [Ping timeout: 480 seconds]
ajxu2 has joined #asahi-dev
ajxu2 has quit []
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]