ChanServ changed the topic of #asahi-gpu to: Asahi Linux GPU development (no user support, NO binary reversing) | Keep things on topic | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-gpu
aratuk has quit [Remote host closed the connection]
aratuk has joined #asahi-gpu
alyssa has joined #asahi-gpu
<alyssa> -next is looking quite a bit less scary
nafod8 has joined #asahi-gpu
nafod has quit [Read error: Connection reset by peer]
nafod8 is now known as nafod
aratuk has quit []
<alyssa> still big, but
<alyssa> 40 commits now
akspecs_ has quit [Remote host closed the connection]
akspecs has joined #asahi-gpu
<i509vcb> Not sure if it is implemented right now, but I believe the hardware supports enough to implement timeline support for DRM sync objects?
<i509vcb> /s/believe/does
<alyssa> i think yes
kesslerd has quit [Remote host closed the connection]
<i509vcb> I'm wondering is the next release going to support GLES 3.0? I have seen a lot of the commit history showing compute related stuff.
<i509vcb> (Although I'd like to try my hand at some vulkan stuff for agx but don't want to cause 2 efforts for it)
<alyssa> we don't really have a release schedule
<alyssa> but yes, gles 3.0 comes after gles 2.0
<alyssa> and gles 3.1 after gles 3.0
<alyssa> and vulkan 1.0 after that
<lina> i509vcb: Timeline sync is implemented, though completely untested ^^
<lina> (I just copied what Xe did)
<i509vcb> Hmm neat, so assuming no bugs it should be effectively automatic to have VK_KHR_timeline_semaphore
<lina> Probably! (I don't know much about Vulkan yet, but the UAPI is designed based on modern Vulkan requirements)
<i509vcb> I personally don't want to bug ella right now until some of the buffer and image copy stuff is pushed in (probably some local changes). But I will stick around and try to help with Vulkan if possible
<lina> alyssa: Did you get a chance to test the new kernel branch? I want to know if it fixes all the brokenness you were running into ^^;;
<i509vcb> I get that it is not your priority right now, but nothing wrong with trying to make it work in parallel
<lina> Definitely, and I think both alyssa and I will be moving towards Vulkan as the GL stuff settles down too ^^
<i509vcb> (I partially want to see Vulkan so I can yeet the EGL code in my compositor)
<lina> I'm actually going to write a doc on how the queue synchronization works in our driver, since I need that to make the GL frontend understandable too, but it should be useful for Vulkan
wintp has quit [Quit: Connection closed for inactivity]
user982492 has joined #asahi-gpu
<alyssa> lina: what's the new kernel branch
<alyssa> I've been running b7b005953e96d9e443ea2edd5e3befd63e911138
<alyssa> works like a charm
<alyssa> (with next)
<alyssa> (except for all the shit piglit provokes but, i'm just playing with registers ;~P)
<lina> alyssa: That's before the fixes, gpu/explicit-sync should fix the piglit explosions and that splat that you saw
<lina> It's also a rebase (and might need a new m1n1 for you) but it's what will be released so I would appreciate it if you can test it ^^
* alyssa eyes clock
<alyssa> sure ok
<lina> alyssa: Is agx/release still the right branch for release (other than that dual source blending thing we need to drop)?
<alyssa> yes please
<alyssa> lina: what happened to my DCP?
<alyssa> reserved-memory node 'framebuffer' not found
<alyssa> adev bind failed: -19
c10l has quit [Quit: Bye o/]
<alyssa> I updated my mini
c10l has joined #asahi-gpu
<lina> Are you sure you updated m1n1?
<alyssa> yes
<lina> To upstream main?
<alyssa> to lina/gpu-wip
<lina> Oh sorry no, that's just my experiments and I hadn't pushed yet ^^;;;
<lina> Pushed now (or just use main)
<alyssa> switched to main
<alyssa> girl you gotta tell me these things :p
<lina> There are no m1n1 changes for agx, it's just DCP that changed
<alyssa> ok
<alyssa> what happened to my AGX?!
<lina> Whaa...
<alyssa> DRM_ASAHI=n and I don't see the option
<alyssa> Guessing Rust is broken again
<lina> "make rustavailable"
<alyssa> rust is available
<lina> Did I mess this up??
<lina> Aaaaa hold on
<lina> Sorry this was a thing I added last minute yesterday and kconfig confuses me
<alyssa> ;/
<lina> alyssa: Pushed, should be fixed, sorry T_T
<alyssa> GPU crashed immediately, try again
<lina> Umm...
<lina> Whaaa...
<lina> How??
<alyssa> I'm going to guess whatever code I just pulled is broken
<alyssa> Or extremely bad luck
<alyssa> But probably the first one
<alyssa> can I downgrade now?
<lina> But it works for me...
<lina> Do you have more dmesg backlog?
<alyssa> no
<lina> The first line there is already broken...
<alyssa> that's just from running kmscube
<lina> Are you on 12.3?
<alyssa> yes
<lina> I don't get it... I really need more dmesg backlog to have a guess at what went wrong there, it's like something is horribly wrong with the fwctl ring...
<lina> And I dind't touch that code in forever...
<alyssa> there's no other dmesg backlog
<lina> OH
<lina> OH
<lina> OMG I forgot repr(C) on that and your Rust compiler must've decided to use a different struct layout aaaa
<alyssa> santa are you ok
<lina> Please try again T_T
<lina> This has always been broken, you just got unlucky hitting it now T_T
<alyssa> Woo
<alyssa> luv the commit msg
<alyssa> and glad i could be a serviceable rubber duck
<lina> ;;
<alyssa> ok yes i have spinny cube again
<alyssa> lina: new kernel survived a piglit run. thanks for the fixes :)
<lina> ^^
<alyssa> and actually the piglit fail/crash number isn't all that different from the older release
<lina> Glad to hear that!
<alyssa> so unless I see something scary in the fails.csv list (haven't looked yet) I'd say agx/release is good to go
<lina> Yay~!
<alyssa> `yeah, nothing here scares me
<alyssa> good to go
<lina> Thank you for testing, and sorry for keeping you up late ^^;;
<alyssa> nw
<alyssa> ok but why is my system hanging trying to open gnome
<alyssa> ;;;;
<lina> Ummmmmmm
<lina> ;;;;;;
<lina> Works here...
<lina> I don't want to keep you up too late but if you can get me some backtraces of relevant stuff and dmesg if anything that might help ^^
<alyssa> sway is going ok
<alyssa> could it be because gnome is a piece of-
<alyssa> ooh, oof, this is your bug after all
<lina> ;;;;;;;;;;;
<lina> kernel or mesa?
<alyssa> kernel
<lina> Any messages?
<alyssa> more missing repr(C)?
<lina> Is there anything earlier? That just looks like the firmware died...
<alyssa> no
<lina> Can you upload your kernel binary somewhere and go to sleep? I can probably track it down running it in the hypervisor.
<lina> Could be a repr(C) thing and your Rust compiler really wants to shuffle structs around for some reason
<alyssa> IDK why it's only happening with gnome
<alyssa> sway + stk is fine
<lina> Added more reprs though it was kinda trivial stuff, I don't know if that's it...
<alyssa> im kinda surprised rust doesn't catch this sort of bug
<lina> It's an FFI thing, you need to set the struct layout... Once I add the Castable thing it should catch some (but not all) of these issues
<lina> I think it's something that should eventually be a core feature
<alyssa> what I mean is, how is it ever sound to get the raw bytes of a repr(Rust) struct
<alyssa> or is this happening in an unsafe{} block with a botched SAFETY comment?
<lina> It isn't, it's all unsafe, yeah
<alyssa> still feels like this is a footgun API
<lina> Hence the Castable thing (that's supposed to mean "safe to get the raw bytes" but this isn't a core language feature yet)
<alyssa> because even in an unsafe{} block it is literally never legal to get raw bytes of repr(Rust)
possiblemeatball has quit [Quit: Quit]
<lina> It is, if you know there is no padding (which can be known)
<alyssa> is that portable?
<lina> You can't assume anything about the layout, but you could restore it into an identical struct
<lina> So that's not unsafe
<lina> Can you check if the last patch fixed it? It's all I've got...
<alyssa> (OK, I hit the issue with firefox in sway on the older kernel. good to know it's not just gnome)
<alyssa> lina: Nope, still no good
<alyssa> https://rosenzweig.io/I is with your patch
<lina> OK, go to sleep sis ^^
<lina> I'll test with your kernel
<alyssa> fiiiiine
<alyssa> nini
<i509vcb> bytemuck does have some safety notes that might be worth considering even though you seem to be rolling your own type -> bytes conversion: https://docs.rs/bytemuck/1.13.1/bytemuck/trait.Pod.html
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alyssa has left #asahi-gpu [#asahi-gpu]
c10l has quit [Read error: Connection reset by peer]
c10l has joined #asahi-gpu
cr1901_ has joined #asahi-gpu
cr1901 has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-gpu
Major_Biscuit has joined #asahi-gpu
MajorBiscuit has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-gpu
nyilas has joined #asahi-gpu
nyilas has quit [Remote host closed the connection]
<lina> OK, alyssa was using the debug allocator and I think we're hitting a firmware bug/race, but I don't think we use that codepath at all in the regular mode so I'm just going to punt on it...
nyilas has joined #asahi-gpu
DarkShadow44 has quit [Quit: ZNC - https://znc.in]
DarkShadow44 has joined #asahi-gpu
DarkShadow44 has quit [Quit: ZNC - https://znc.in]
DarkShadow44 has joined #asahi-gpu
commandoline has joined #asahi-gpu
commandoline has quit []
commandoline has joined #asahi-gpu
<lina> Wrote this to attach to the DRM submission ^^ (cc ella-0 & alyssa): https://github.com/AsahiLinux/docs/wiki/SW:AGX-driver-notes
as400 has quit [Remote host closed the connection]
as400 has joined #asahi-gpu
nyilas has quit [Remote host closed the connection]
karolherbst_ is now known as karolherbst
hightower2 has joined #asahi-gpu
alyssa has joined #asahi-gpu
<alyssa> lina: nit, "the VDM level (in the GPU command stream)"
<alyssa> *GX actually has a "control stream" in powervr lingo, not a command stream
<alyssa> the distinction being, it isn't executed / interpeted in any meaningful way, it's not structured as commands or bytecode or anything
<alyssa> it's just a bunch of control packets one after the other, plus a link command to jump between control streams
<alyssa> this is very different than GPUs with real command streams,
<alyssa> e.g. Mali-G610 exposes an entire Turing-complete-by-design ISA where the state vector is passed in registers that the driver sets with MOV_IMM32 instructions
<alyssa> but that has general purpose "load/store registers from/to memory" instructions, conditional branching based on the values of registers, a simple integer ALU, etc
<alyssa> generally this means that AGX is easier to program -- and the AGX control stream is a lot more compact than the Mali command stream -- but there's a pretty low ceiling for what you can do with AGX in terms of indirection
<alyssa> there's hardware support for a few important types of indirects, where there's a special control word to do an indirect draw or whatever
<alyssa> but if you have an API requirement that the hw doesn't accommodate, you're kinda screwed
<alyssa> notably, multiDrawIndirect, which is like draw indirect but now draws an arbitrary number of draws indirectly with the draw count loaded from memory
<alyssa> on Mali-G610, the driver implements this with a loop in the command stream
<alyssa> on AGX, we have no way to express a loop, it's not turing complete by itself
<alyssa> so either we don't do multiDrawIndirect, or we implement it with a compute kernel that generates a control stream with all the draws at runtime and then stream_links to it
<alyssa> (which is kinda horrible, because you need to plumb the draw ID into the shaders as a special uniform, but changing the uniform state means re-emitting a whole pile of shader state. it can be done with a "clone and patch" technique, or with a sufficient horrible compute kernel. but it's not nice.)
<alyssa> (but Metal's "GPU indirect buffers" are exactly this, and if MoltenVK supports multiDrawIndirect - dont remember if they do - it's with this)
<alyssa> another notable one, conditional rendering, which lets you predicate draws on an occlusion query passing
<alyssa> on Mali, this is really easy!
<alyssa> LOAD the result of the query and branch over the draws based on the result
<alyssa> (*Mali-G610, older Malis this all suuuucks far worse tha AGX)
<alyssa> on AGX, this is a lot more tricky
<alyssa> unless there's a sufficiently general conditional stream link, we again need to dispatch a compute kernel for this
<alyssa> (feel free to replace "Compute kernel" with "internal vertex shader" if you want this to all happen on the VDM, btw)
<alyssa> this compute kernel though isn't too horrible, thankfully
<alyssa> in the control stream after emitting the compute, always emit a stream link and put all the draws to predicate in a new control stream
<alyssa> and then the compute kernel will just patch the link target based on the query result
<alyssa> none of this is *challenging*, mind you
<alyssa> and perf will be ok unless the app goes crazy with this stuff
<alyssa> but it's still a really steep cliff you fall off as soon as you leave the comfy confines of what the hw designers intended
<alyssa> (otoh, as far as I can tell, Mali-G610 was uniquely designed around supporting multiDrawIndirect and that's it ;P)
<alyssa> lina: "Blit command support will be added in a future driver"
<alyssa> ....uh
<alyssa> 'since it is not safe to do so'
<alyssa> and not stable
<alyssa> 'Upstreaming blockers (affect current draft UAPI):'
<alyssa> also, scratch memory
<alyssa> I don't want to block upstreaming on me figuring out a spiller so I'll probably just wire up load_scratch/store_scratch as a proof-of-concept
<alyssa> but this is absolutely required for a production driver and I don't want a UAPI stabilized without it
<alyssa> probably super easy in the kernel side, though
<alyssa> i hope
alyssa has quit [Quit: leaving]
cy8aer has quit [Remote host closed the connection]
cy8aer has joined #asahi-gpu
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bisko has joined #asahi-gpu
c10l has quit [Quit: Bye o/]
balrog has quit [Remote host closed the connection]
possiblemeatball has joined #asahi-gpu
kesslerd has joined #asahi-gpu
kesslerd has quit [Quit: Konversation terminated!]
kesslerd has joined #asahi-gpu
karolherbst_ has joined #asahi-gpu
iaguis has joined #asahi-gpu
karolherbst has quit [Ping timeout: 480 seconds]
balrog has joined #asahi-gpu
alyssa has joined #asahi-gpu
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<lina> alyssa: It's a wiki, you can just edit it~
<alyssa> woahh
<alyssa> lina: Hmm for glGenerateMipmap() i guess it shouldn't be too hard to do a single drm_asahi_submit with all the different batches that make it up
<alyssa> maybe less heavyhanded than hooking up the blit queue
<alyssa> and still get most of the benefit
<alyssa> I guess the "right" way to do it is with a background program and no draw calls
<alyssa> and if you do that, you don't need the VDM for anything which is where the blit queue comes in
<alyssa> yeah, ok, sure whatever
<alyssa> glGenerateMipmap is silly but a bunch of benchmarks have it in a hot path so v_v
<alyssa> and faster game load screens is good maybe
<mort_> Hey, I'm trying to build the kernel according to this pkgbuild: https://github.com/AsahiLinux/PKGBUILDs/blob/d66008ea33ce6547a806fd197688a9344c02f6ef/linux-asahi/PKGBUILD -- and it works, but the edge kernel it builds doesn't seem to have an asahi.ko.zst.. I don't understand why, but it seems like the config file for the edge build somehow gets
<mort_> overwritten?
<mort_> the src/linux-asahi-blah/build/edge/.config.old file ends up with the stuff from config.edge (including CONFIG_DRM_ASAHI=m), but src/linux-asahi-blah/build/edge/.config ends up without it
<jannau> mort_: no user support here, see /topic
<mort_> ah sorry, I should've read that before asking.
Bey0ndB1nary has joined #asahi-gpu
chipxxx has joined #asahi-gpu
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #asahi-gpu
bluetail9 has quit [Ping timeout: 480 seconds]
maria has quit [Ping timeout: 480 seconds]
Bey0ndB1nary has quit []
Major_Biscuit has quit [Ping timeout: 480 seconds]
bluetail9 has joined #asahi-gpu
maria has joined #asahi-gpu
<alyssa> marcan: so when are you release this thing
* jannau looks on the clock and the magic eight ball answers tomorrow
<alyssa> jannau: no but i just asked so you need to double it
<alyssa> so two days from now, got it
zshrc has joined #asahi-gpu
karolherbst_ is now known as karolherbst
zshrc has quit [Ping timeout: 480 seconds]
zshrc has joined #asahi-gpu
zshrc is now known as Guest6969
zshrc has joined #asahi-gpu
Guest6969 has quit [Ping timeout: 480 seconds]
zshrc has quit [Quit: leaving]
<jannau> short test of agx/release shows no problems on a m1 ultra
bluetail94 has joined #asahi-gpu
<alyssa> Woop
bluetail9 has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
i509vcb has joined #asahi-gpu
<jannau> pink/violet boxes/triangles during plasma/wayland login on m2, very briefly
<alyssa> Noooo
<jannau> reproducible, boxes, maybe 16x8, 1 or 2 frames
cr1901_ is now known as cr1901
<jannau> reproduces with ~50% in the first 3 login attempts after boot and seems to be very unlikely to reproduce after that (3 repeats)
<jannau> no, still reproducible later. so maybe reproducible in 10 to 15%
iaguis has quit [Quit: leaving]
<jannau> not reproducible on the m1 ultra in over 30 tries with the exact same m1n1/kernel/mesa
possiblemeatball has quit [Quit: Quit]
D-Spirits has joined #asahi-gpu
possiblemeatball has joined #asahi-gpu
bluetail94 has quit []
D-Spirits has quit [Quit: D-Spirits]
c10l has joined #asahi-gpu
amada95 has joined #asahi-gpu
kesslerd_ has joined #asahi-gpu