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
swampertx[m] has joined #asahi-gpu
xorly[m] has joined #asahi-gpu
bluetail0 has joined #asahi-gpu
braindeadmosquito[m] has joined #asahi-gpu
AndrewLee[m] has joined #asahi-gpu
nulltemp[m] has joined #asahi-gpu
handofstand[m] has joined #asahi-gpu
ella-0[m] has joined #asahi-gpu
AdityaJS[m] has joined #asahi-gpu
Makusu[m] has joined #asahi-gpu
Andy[m] has joined #asahi-gpu
TellowKrinkle[m] has joined #asahi-gpu
The_DarkFire_[m] has joined #asahi-gpu
boulabiar[m] has joined #asahi-gpu
catinahatisback[m] has joined #asahi-gpu
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #asahi-gpu
dgarciagarcia[m] has joined #asahi-gpu
TristenNollman[m] has joined #asahi-gpu
ofir8989[m] has joined #asahi-gpu
ryanmitts[m] has joined #asahi-gpu
SuchirMishra[m] has joined #asahi-gpu
Sobek[m] has joined #asahi-gpu
ryanhrob[m] has joined #asahi-gpu
pedrohos[m] has joined #asahi-gpu
katatafjsh[m] has joined #asahi-gpu
hpux735[m] has joined #asahi-gpu
Kevy[m] has joined #asahi-gpu
mofux[m] has joined #asahi-gpu
madpro[m] has joined #asahi-gpu
HuayuZhangLevi[m] has joined #asahi-gpu
princesszoey has quit [Quit: The Lounge - https://thelounge.chat]
princesszoey has joined #asahi-gpu
waytrue[m] has joined #asahi-gpu
Mary has quit [Quit: The Lounge - https://thelounge.chat]
Mary has joined #asahi-gpu
threerik[m] has joined #asahi-gpu
icepie[m] has joined #asahi-gpu
pashencija[m] has joined #asahi-gpu
sunyiynus[m] has joined #asahi-gpu
ognju[m] has joined #asahi-gpu
defolos[m] has joined #asahi-gpu
pazyleon[m] has joined #asahi-gpu
pg12_ has quit []
pg12 has joined #asahi-gpu
princesszoey5 has joined #asahi-gpu
kl22[m] has joined #asahi-gpu
l1npengtul[m] has joined #asahi-gpu
princesszoey has quit [Quit: The Lounge - https://thelounge.chat]
princesszoey5 is now known as princesszoey
Soroush has joined #asahi-gpu
princesszoey has quit [Quit: The Lounge - https://thelounge.chat]
princesszoey has joined #asahi-gpu
XProtocol[m] has joined #asahi-gpu
daftfrog[m] has joined #asahi-gpu
nehbyua[m] has joined #asahi-gpu
firox263[m] has joined #asahi-gpu
larabee[m] has joined #asahi-gpu
HauXs[m] has joined #asahi-gpu
badlydrawnface[m] has joined #asahi-gpu
polarn[m] has joined #asahi-gpu
zhxchen17[m] has joined #asahi-gpu
balrog has quit [Ping timeout: 480 seconds]
sajattack[m] has joined #asahi-gpu
bluetail03 has joined #asahi-gpu
latosca[m] has joined #asahi-gpu
bluetail0 has quit [Ping timeout: 480 seconds]
bluetail03 is now known as bluetail0
Tsic[m] has joined #asahi-gpu
dantedrac[m] has joined #asahi-gpu
espo has quit [Ping timeout: 480 seconds]
skoobasteeve has quit [Ping timeout: 480 seconds]
balrog has joined #asahi-gpu
princesszoey has quit [Quit: The Lounge - https://thelounge.chat]
princesszoey has joined #asahi-gpu
pjakobsson has joined #asahi-gpu
princesszoey has quit [Read error: Connection reset by peer]
princesszoey has joined #asahi-gpu
SSJ_GZ has joined #asahi-gpu
princesszoey has quit [Quit: The Lounge - https://thelounge.chat]
princesszoey has joined #asahi-gpu
goldsoultheory has joined #asahi-gpu
princesszoey has quit [Quit: The Lounge - https://thelounge.chat]
princesszoey has joined #asahi-gpu
princesszoey has quit [Read error: Connection reset by peer]
Major_Biscuit has joined #asahi-gpu
cr1901_ has joined #asahi-gpu
princesszoey has joined #asahi-gpu
cr1901_ has quit [Read error: Connection reset by peer]
princesszoey has quit [Remote host closed the connection]
DarkShadow44 has quit [Quit: ZNC - https://znc.in]
cr1901 has quit [Ping timeout: 480 seconds]
DarkShadow44 has joined #asahi-gpu
princesszoey has joined #asahi-gpu
DarkShadow44 has quit []
DarkShadow44 has joined #asahi-gpu
princesszoey has quit [Remote host closed the connection]
princesszoey has joined #asahi-gpu
princesszoey has quit [Quit: The Lounge - https://thelounge.chat]
princesszoey has joined #asahi-gpu
kov has quit [Quit: Coyote finally caught me]
bluetail0 has quit [Ping timeout: 480 seconds]
ferrypie[m] has joined #asahi-gpu
kov has joined #asahi-gpu
vup has joined #asahi-gpu
mkurz has quit [Quit: Leaving]
bluetail0 has joined #asahi-gpu
cr1901 has joined #asahi-gpu
yamii_ has joined #asahi-gpu
yamii has quit [Read error: Connection reset by peer]
yamii_ has quit [Ping timeout: 480 seconds]
yamii_ has joined #asahi-gpu
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jlco_ has joined #asahi-gpu
jlco has quit [Ping timeout: 480 seconds]
goldsoultheory has joined #asahi-gpu
<jannau> lina: is the dcp issue my or your problem? just started watching the last ~20 minutes
Major_Biscuit has quit [Ping timeout: 480 seconds]
<lina> I think it's your problem, but it's not a blocker for what I'm trying to do ^^
<alyssa> what's the issue?
zzywysm has quit [Quit: Textual IRC Client: www.textualapp.com]
<lina> glmark2 makes it go explodey
<alyssa> oh, yeah, ok
<jannau> I didn't stop the video, I spotted an atomic_disable
<alyssa> jannau: even without agx in the loop, closing compositors (eg quitting sway to return to the tty) crashes dcp... I don't think that happened on my original prototype but IDK what would've changed. I think you mentioned you know about this issue?
<alyssa> might that be the same bug as glmark2 is hitting?
<jannau> alyssa: I think I've fixed that
<alyssa> OK
<alyssa> i haven't uprevved in a while, will need to for agx though ;)
<jannau> and lina should have the fix
<alyssa> hmm, ok
<jannau> it makes sense to wait at least a few days, we're going to merge iommu mapping handling in m1n1 soon
<jannau> that unfortunately requires devicetree changes compared to what lina merged so it might take a few days until everything is sorted out
<alyssa> sure
<alyssa> i've got macOS side work to do, not actually looking forward to fixing glamor anyway :p
<jannau> I might have a workaround for the most glaring glamor bug. I hooked the cursor plane up and copy its framebuffer if it's too much off-screen
<alyssa> I am missing a lot of context I think
<jannau> not sure if I should publish that though
<alyssa> I assumed glamor was blocked on mesa bugs
<alyssa> What do cursor planes have to do with it?
<alyssa> or is there a bug drawing the cursor in GL and using a plane offloads from AGX to DCP to workaround?
<alyssa> (but of course cursors are differently broken in DCP hence the copy?)
<jannau> the cursor triggered the most glaring glamor rendering bugs
<alyssa> delightful
<lina> I think it was drawing 512x512 squares for the cursor or something like that ^^
<alyssa> what a delight
<boulabiar[m]> So did you get over the gpu restart each frame issue today?
<lina> Nope!
<lina> Now it crashes even more! (Which is probably a good thing for debugging)
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goldsoultheory has joined #asahi-gpu
goldsoultheory has quit []
goldsoultheory has joined #asahi-gpu
<eric_engestrom> lina: I just randomly saw ARM64_ERRATUM_2441009 "Cortex-A510: Completion of affected memory accesses might not be guaranteed by completion of a TLBI"; might be relevant to your TLB issue?
<eric_engestrom> (in kernel config)
<eric_engestrom> (sorry if this is irrelevant, and/or if you've already seen it :)
<lina> I doubt Apple's cores have Cortex errata... ^^;
<eric_engestrom> no, but perhaps the same kind of thing applies?
<eric_engestrom> I don't really know anything about all this so I'm really just guessing
<lina> I actually don't think I have a TLB issue at this point, at least not with the GPU. As far as I can tell from the m1n1 experiment, TLBI actually works fine
<lina> I might still have a TLB issue with the coprocessor, which was being hidden by the GPU shutdown thing beacuse I think the coprocessor shuts down shortly after the GPU (so it mostly worked in practice)
<lina> But there's something else wonky going on with the GPU. If I force it to stay on on purpose, sometimes it crashes on the second frame, sometimes a bit later.
<lina> For the coprocessor I'm just never unmapping/freeing anything for now, to eliminate variables (besides, I plan to do that in my allocator later on anyway, there's no good reason to thrash those mappings)
chipxxx has joined #asahi-gpu
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #asahi-gpu
DarkShadow44 has quit [Quit: ZNC - https://znc.in]
DarkShadow44 has joined #asahi-gpu
<jannau> set_digital_out_mode(color=-1, timing=43) doesn't look healthy (from dcp error from the stream at 10:04:29)
<jannau> drm complains that the driver didn't call drm_crtc_vblank_off
DarkShadow4444 has joined #asahi-gpu
DarkShadow44 has quit [Ping timeout: 480 seconds]
<alyssa> jannau: ...no, that does not indeed.
<alyssa> maybe we need a WARN_ON(mode < 0) in there
<alyssa> or more precisely WARN_ON(IS_ERR(mode))
<alyssa> (I don't remember how the parser worked ..)
* alyssa reads the code
<alyssa> this thing really wants to be rust doesn't it.
<jannau> I don't think it's the parser's fault. this happens when starting glmark2-es2-drm after it already booted
<sven> DCP needs less WARN_ON and nit
<sven> *not more
<sven> warn_on spams dmesg and most of the time the stack isn’t all that useful because it will always be the same
<jannau> I guess glmark selects an an unusual mode with the capture card and dcp doesn't verify it
<alyssa> sven: what is the right way to do asserts then
<alyssa> asserts are the best tool we have to write correct code
<sven> dev_err or something
<alyssa> I thought kernel C assert() is just WARN_ON(!)
<sven> there are also people who run kernels with panic on warn
<alyssa> That is the right behaviour yes
<sven> so if DCP does something slightly unexpected you just panicked the entire kernel
<alyssa> An assertion failure means a bug in my code.
<alyssa> NOT a bug in the firmware or the device or the userspace
<sven> iirc there are at least a few warns inside DCP that are more like "dcp did something strange"
<alyssa> Those should all be errors that become dev_err and should never be asserted it
<alyssa> Okay, well, that's wrong, complain to Alyssa about that.
<sven> :D
<sven> maybe i'm wrong, i just skipped over the code fwiw
<alyssa> no i'm looking now
<sven> but some of them looked like they want to be dev_err instead
<alyssa> I see a bunch of legitimate asserions and a bunch of bogus ones that should indeed be dev_err, bah
<alyssa> static u8 dcp_pop_depth(u8 *depth)
<alyssa> { WARN_ON((*depth) == 0);
<alyssa> that is a legitimate assertion, it can only ever fail due to a bug in the dcp kernel driver
<alyssa> if (WARN(dcp_channel_busy(&dcp->ch_cmd), "unexpected busy channel") ||
<alyssa> WARN(!dcp->connector->connected, "can't flush if disconnected")) {
<alyssa> these are bogus assertions that should be dev_err instead
<alyssa> WARN_ON(endpoint != DCP_ENDPOINT);
<alyssa> this one is bogus
<alyssa> actual bug though: if no modes match, the mode parser returns 0 (success) with best mode = -1
<alyssa> but dcpep.c assumes 0 means there's a valid mode
<alyssa> one of those needs to change, idk what colour the bikeshed should be
<jannau> I'll fix it and look at the WARN_ONs
<jannau> dcpep.c is now iomfb.c btw
<alyssa> seems legit
<jannau> not yet what is used in the agx tree
<sven> and i have some bastard tree forked off a few commits ago that implement yet another dumb parser for these EPIC things :(
<sven> let me see if I can at least still rebase
<alyssa> is dcp getting RiiR'd or not I can't remember
<sven> lol, i also have a commit in my tree to move some dev_dbg to tracepoints
<alyssa> I'd rather it weren't but otoh maybe the mode parser should be.
<sven> oh well..
<sven> RiiR?
<jannau> lol, with a clash in the filename? I looked at tps6598x as template
<jannau> re-implemented in rust
<sven> yup, because I also used tps6598x as template :D
<sven> meh, i'll take care of that later this week
<alyssa> RiiR is a very important algorithm for being friends with lina~ ;-p
<alyssa> acronym
<sven> ah, don't really care. if you want to have dcp rust I'll gladly learn it to implement the EPIC crap there *shrug*
<alyssa> i don't
<jannau> I won't mind Rust and depending on how much Apple changed the DCP rpc in ventura I think it could be useful
<jannau> on the other hand judging by the amount of changes they did between macos 11 and 12 it should be manageable in C
* alyssa shrugs
<alyssa> you're the dcp maintainer now, it's your call :p
<alyssa> o:)
<sven> nerd sniping successful :>
chipxxx has quit [Read error: Connection reset by peer]
chipxxx has joined #asahi-gpu
<alyssa> lol
chipxxx has quit [Read error: Connection reset by peer]
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goldsoultheory has joined #asahi-gpu
mactroon65[m] has joined #asahi-gpu
mactroon65[m] was banned on #asahi-gpu by ChanServ [*!*@2001:470:1af1:101::f0c2]
mactroon65[m] was kicked from #asahi-gpu by ChanServ [You are not permitted on this channel]
mactroon66[m] has joined #asahi-gpu
<mactroon66[m]> hello trannies
<mactroon66[m]> have you dilated your stinkditches today yet
<mactroon66[m]> rust is the biggest disgrace that happened to linux kernl
<mactroon66[m]> they should have adopted c++ instead of the tranny sjw language
mactroon66[m] was kicked from #asahi-gpu by ChanServ [You are not permitted on this channel]
<alyssa> hello fruit farmer
<alyssa> query sven
<jannau> lina: https://github.com/jannau/linux/commit/60babbde481e945a979b2c1c368d93d7cbdce1f5 should fix the dcp issue. newer tree than what you merged but that commit should be cherry-pickable
<jannau> starnge that dcp reports timing modes without color modes
<jannau> not sure why glmark2 hits that. For some reason it must chose a different mode than all other software
<jannau> maybe it tries to select the mode with the highest refresh rate and you capture card additional unusual modes besides the 64Hz FullHD mode
<alyssa> that sounds dcp
goldsoultheory has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
SSJ_GZ has quit [Ping timeout: 480 seconds]
bisko has quit [Ping timeout: 480 seconds]