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
jeisom has quit [Ping timeout: 480 seconds]
<i509vcb> alyssa: looking at https://gitlab.freedesktop.org/asahi/mesa/-/blob/agxv/main/src/vulkan/runtime/vk_meta_copy.c#L558 multiple layers aren't handled yet, is this something more complicated than just run do_copy at different locations a few times or does some other part of agxv need to compensate for this?
<alyssa> shrug
<alyssa> I'm told Collabora is working on finishing vk_meta_copy so I wasn't touching it
<i509vcb> ok
<i509vcb> Well I knew it would happen eventually that I'd cause kde to hang
<i509vcb> Didn't expect running a semaphore test to do that
<alyssa> yeah the process isolation on these things isn't.. grat
<alyssa> great
<alyssa> when I was doing Mesa on macOS, i got macOS to fail in all sorts of creative ways..
<i509vcb> I'm guessing this type of hang I can't fix from just trying to ssh in...
<alyssa> It might be
<alyssa> I regularly have to ssh in and pkill sway and that's enough to fix
<alyssa> haven't had to reboot in months, lina's kernel is rock solid <3
<i509vcb> I think the compositor hung if I can't adjust volume, well I don't know the local IP off head so I guess I need to reboot anyways
<i509vcb> Wayland compositor handover would be great for this type of situation...
<i509vcb> Wondering is there a reason why dmesg gets swamped with "Blocking due to compute queue full"?
<alyssa> apparently i have that too, that's neat
<i509vcb> I noticed that spam when I ran dEQP-VK.synchronization.basic.binary_semaphore.chain which failed before a reboot and works after a reboot
<alyssa> Oof
<i509vcb> > WorkQueue: Cannot submit, but queue is empty?
<i509vcb> That seems weird
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
VinDuv has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi-gpu
marvin24 has quit [Ping timeout: 480 seconds]
<lina> That sounds like a bug...
<lina> The driver is really good with memory safety stuff but there are still definitely bugs in the queuing logic/etc (plus drm_sched problems) that can cause things to get stuck I think...
<lina> (And then if a fence never gets signaled that can jam all of KDE)
<i509vcb> Flipping the bits in agxv to turn on timeline semaphores just seems to hang forever on dEQP-VK.synchronization.basic.timeline_semaphore.one_queue
<i509vcb> I guess this isn't tested so no idea what could be wrong there
<lina> Oh it might be that timeline stuff is just completely broken
<lina> That is totally untested, I just wrote it blind...
<lina> If you have a branch/testcase I can use to try it I can look at it tomorrow ^^
<i509vcb> Give me a min and I'll push my current agxv branch so you can look at that
<i509vcb> dEQP-VK.synchronization.basic.timeline_semaphore.* all hang I believe
Z750 has quit [Quit: Ping timeout (120 seconds)]
Z750 has joined #asahi-gpu
<i509vcb> I also tested with setting sync_types[1] to &device->sync_timeline_type.sync and then putting NULL at [2] but that just fails on an assert in common code
<i509vcb> It's possible I don't exactly know what to do with the vk_sync stuff
<alyssa> i509vcb: welcome to how the kernel driver is built
<i509vcb> however other drivers seem to do fine with null at [2] and [1] being the timeline sync type
<alyssa> lina writes kernel code without being able to test, i write mesa code and find the kernel is broken, lina debugs kernel with my mesa branch, i fix my mesa branch once the kernel is fixed because whoops i also wrote buggy mesa code
<alyssa> or sometimes the other way around
<alyssa> :~)
<alyssa> the broken branch hot potato
<alyssa> lina and i are experts :~)
<i509vcb> The assert I hit has this ominous "We can only have one timeline mode" comment
cylm_ has joined #asahi-gpu
Whistler_ has joined #asahi-gpu
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
cylm_ has quit [Ping timeout: 480 seconds]
cr1901_ has joined #asahi-gpu
cr1901 has quit [Read error: Connection reset by peer]
jennifilm has joined #asahi-gpu
WindowPa- has joined #asahi-gpu
WindowPain has quit [Read error: Connection reset by peer]
ourdumbfuture has joined #asahi-gpu
cylm_ has joined #asahi-gpu
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
cylm_ has quit [Ping timeout: 480 seconds]
zane has joined #asahi-gpu
jeisom has joined #asahi-gpu
ourdumbfuture has joined #asahi-gpu
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-gpu
iyes has joined #asahi-gpu
ATiltedTree_ has joined #asahi-gpu
compassion1785 has quit [Quit: lounge quit]
ATiltedTree has quit [Ping timeout: 480 seconds]
<iyes> So I made an account on FDO gitlab, but I can't fork asahi/mesa? It says project limit reached. Do I need some special permissions on my account? How am I going to be able to hack on the source code and make MRs if I can't fork?
ATiltedTree_ is now known as ATiltedTree
<iyes> Oh! Okay!
anarcat[m] has joined #asahi-gpu
compassion1785 has joined #asahi-gpu
cylm_ has joined #asahi-gpu
Dementor has joined #asahi-gpu
<iyes> Lol after not having worked with C for years, only Rust, reading mesa source code now (studying NIR apis) and seeing all the various pointers to different structs everywhere, is filling me with dread and paranoia. :D Everything feels so fragile! I guess I'll get used to it...
<alyssa> you will not :3
<alyssa> c is terrifying
<rosefromthedead> hahahah
<rosefromthedead> "you're in for a world of pain :3"
<iyes> Does mesa have any sort of browse-able API docs generated from the source code itself? something similar to what rustdoc/docs.rs for rust projects?
<iyes> Or am I too spoiled by rust's nice dev tools and having unreasonable expectations here? :D
<alyssa> a bit
compassion1785 has quit [Quit: lounge quit]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<iyes> Yea I looked at those things, but they seem to be incomplete and human written. In Rust projects (and C/C++ projects that use something like Doxygen), it's so nice to able to learn a codebase by using a web browser to search around and click around to explore all the different functions, structs, etc. :)
<iyes> I guess no such thing exists here. It's fine. I got LSP with clangd working, and I can navigate around the source code easily from my text editor. I'll try to study things that way.
compassion1785 has joined #asahi-gpu
compassion1785 has quit []
compassion1785 has joined #asahi-gpu
possiblemeatball has joined #asahi-gpu
zane has quit [Quit: WeeChat 4.0.3]
<alyssa> that's doxygen
<alyssa> iirc
possiblemeatball has quit [Quit: Quit]
<iyes> What is an agx_bo ?
<iyes> Or I guess, a "BO" more generally?
<i509vcb> buffer object
<iyes> Oh! *facepalms*
<iyes> That makes sense, that user-facing apis like UBOs/VBOs/SSBOs/etc would be backed by common code for gpu buffers more generally.
possiblemeatball has joined #asahi-gpu
<iyes> How does mesa know what GL extensions to advertise as supported (say, in glxinfo output)? What exactly in the source code of a given driver (say, in our case asahi) results in a given extension to be reported as supported/available?
<alyssa> iyes: based on the PIPE_CAPs in agx_pipe.c
<alyssa> although I would encourage new developers to focus on Vulkan, there's a lot more low-hanging fruit there for both bugs and features
<alyssa> the GL driver, I kinda did all the easy stuff and now it's just the hard stuff left :p
<iyes> Hahah, understandable
<i509vcb> I think some parts of gallium also check the screen vtable as well
<i509vcb> for extensions
<iyes> I still want to learn how things work, though
<iyes> Out of curiosity, alyssa , based on your judgement, how hard are cubemap array textures? Sample rate shading?
<alyssa> cubemap arrays are easy
<alyssa> but the GL extension depends on geometry shaders for silly historical reasons
<alyssa> *GLES
<alyssa> sample shading is hard but already works, just waiting to be released.
<iyes> Oh okay that makes sense why cube map arrays are not advertised as supported in GLES/GL
<iyes> That's unfortunate, it was the reason why Bevy game engine's 3d rendering did not work on Asahi when I tried it.
<i509vcb> I do know that you can run wgpu in it's downlevel gles 3.0 mode currently
<i509vcb> but the fancy stuff will need vulkan for wgpu to expose it
<iyes> Yep yep, Bevy works on asahi when using the GLES backend
<iyes> But Bevy's 3D PBR materials use cube map arrays
<iyes> So 3D examples errored on the missing extension
<iyes> But anyway, this is off-topic
<i509vcb> Back before wgpu-hal and in the gfx-hal days, there was a proper GL 4.6 backend but that never really got ported over
ourdumbfuture has joined #asahi-gpu
<i509vcb> lina: assuming the driver supports timeline sync objects the branch I linked last night should be in a testable state
iyes has quit [Ping timeout: 480 seconds]
<i509vcb> where does the timeline kernel branch live again?
nela has quit [Ping timeout: 480 seconds]
iyes has joined #asahi-gpu
nela has joined #asahi-gpu
Guest8982 has quit [Quit: Bridge terminating on SIGTERM]
rhysmdnz has quit [Quit: Bridge terminating on SIGTERM]
iyes has quit [Ping timeout: 480 seconds]
rhysmdnz has joined #asahi-gpu
Guest9188 has joined #asahi-gpu
cr1901_ is now known as cr1901
iyes has joined #asahi-gpu
<Mary> Hmm agxv_GetPhysicalDeviceImageFormatProperties2 isn't filling maxExtent.depth, what would be an appropriate value to report?
iyes has quit []
jeisom has quit [Quit: Leaving]
<i509vcb> 1d and 2d have a depth of 1
<i509vcb> 3d not so sure
crabbedhaloablut has joined #asahi-gpu
<alyssa> Mary: arrays can have up to 2048 layers
<Mary> we report 8192 for maxImageDimension3D so I suppose that's what we should be doing here
<Mary> oh
<alyssa> 3D can be up to 8192 depth
<Mary> Will fix that then, thanks
<i509vcb> alyssa do you happen to know what kernel branch the timeline stuff is implemented in?
jeisom has joined #asahi-gpu
<alyssa> I thought it's in what we ship
<i509vcb> I was going to try to debug myself but I guess it happens with that's shipped so
<alyssa> gpu/rust-wip branch anyway
<alyssa> although that has uapi bumpage
<alyssa> which i was going to do next week
<alyssa> rebase agxv i mean
<i509vcb> Well there are other things I can do in the driver until then
jeisom has quit [Ping timeout: 480 seconds]
jeisom has joined #asahi-gpu
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
possiblemeatball has quit [Quit: Quit]
ourdumbfuture has joined #asahi-gpu
VinDuv has joined #asahi-gpu
<i509vcb> restarting ide over ssh... I'd think just pkill -9 kwin_wayland but now am on a black screen
<i509vcb> /s/ide/kde
<i509vcb> What's meant to be the intended way to do this?
<alyssa> i509vcb: I use multi-user.target instead of graphical.target and start (sway in my case most of the time) manually from the tty on boot, so then the pkill returns the tty
<alyssa> not sure what the Right way is
crabbedhaloablut has quit []
<i509vcb> Not sure where to look to handle nir_intrinsic_load_num_workgroups in agx_emit_intrinsic
<i509vcb> Hmm nvm I see something in asahi gallium
<alyssa> i509vcb: the nontriviality is CmdDispatchIndirect
<alyssa> you don't (in general) know the number of workgroups on the cpu
<i509vcb> in gallium you seem to load the number of workgroups in a sideband storage?
<i509vcb> although that might not be whats good for vulkan
<alyssa> the way I handle this in gallium is..
<alyssa> 1. For direct dispatch, I upload the workgroup count to GPU memory at dispatch time.
<alyssa> 2. Now regardless of direct or indirect, we have a GPU address to the workgroup count in the common format
<alyssa> 3. That GPU address is mapped to uniform registers for any shader that reads num_workgroups
<alyssa> 4. num_workgroups turns into a read from those uniform registers
<i509vcb> indirect you are told how many workgroups you have?
<alyssa> no, indirect the app passes the count in gpu memory
<alyssa> (it could be written by some other compute shader, you can't read it from the cpu)
<alyssa> .
possiblemeatball has joined #asahi-gpu
<jannau> lina: did you find an alternative solution for display/gpu testing on the m2 ultra? I finally got dcpext0/dp-altmode to work on t6020
<i509vcb> there was an agx opcode reference somewhere if I recall?
<jannau> anyway, I'll prepare a branch for testing on the mac pro (and the m2 max macbook pro)
<i509vcb> I learned of nir_lower_compute_system_values which seems to handle nir_intrinsic_load_num_workgroups
<i509vcb> is there a reason the gallium driver has it's own bespoke thing there with AGX_SYSVAL_TABLE_GRID?
<i509vcb> (v3dv and a few other drivers use lower_compute_system_values)
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #asahi-gpu
<alyssa> i509vcb: becuase that doesn't actually handle it
<alyssa> it just relies on the driver passing in a constant count
<alyssa> which again you don't know for indirect dispatch
<i509vcb> ok so agxv can't use that
<alyssa> that's an optimization for mesh shaders
<alyssa> not compute
alyssa has quit [Quit: alyssa]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-gpu
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-gpu
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]
manawyrm has joined #asahi-gpu
cylm_ has quit [Ping timeout: 480 seconds]
<jannau> lina, marcan: https://github.com/AsahiLinux/m1n1/pull/320 required m1n1 changes, can be merged immediately
<jannau> kernel branch: https://github.com/jannau/linux/tree/asahi-6.4-7pre-dcpext_dp_t602x - only works on t602x with 13.5 fw, tested on j474s
<jannau> only atc1 works, should be on all machines the port next to the usb-c port with serial
<jannau> requires 'pd_ignore_unused' (haven't checked why yet), there seems to be some kind of memory hazard in afk.c or dptx.c. works for me only if compiled with clang
<jannau> This is a problem on fedora since clang and bindgen use libllvm.so from llvm-15/16 which breaks build with asahi
<jannau> other than that it seems to work ok. comes up reliably at boot and after display standby. only lightly tested
alyssa has joined #asahi-gpu
<alyssa> since rebasing I'm getting weird Chromium issues
<alyssa> sometimes it fails to start properly and spams stderr with messages like
<alyssa> Errors:
<alyssa> link failed but did not provide an info log
<alyssa> [4983:4983:0817/194416.716259:ERROR:shared_context_state.cc(81)] Skia shader compilation error
<alyssa> I can't tell if this a Mesa bug or a Chromium one
<alyssa> MESA_SHADER_CACHE_DISABLE=1 'seems' to workaround which points at a Mesa bug but it's hard to say
<alyssa> The on-screen symptom is that Chromium rendering is totally broken
<jannau> alyssa: Chromium has its own shader cache
<jannau> ~/.config/chromium/Default/GPUCache
anarcat[m] has left #asahi-gpu [#asahi-gpu]
<jannau> see https://github.com/AsahiLinux/linux/issues/72 there is an upstream bug but I think we're partly to blame as well since the mesa version doesn't change
<alyssa> jannau: oh, good
<alyssa> here I was worried this was a regression I introduced ;~P
<alyssa> thanks :)
<alyssa> OpenGL core profile version string: 3.1 Mesa 23.3.0-devel (git-2866d6991e)
<alyssa> this has the commit hash
<alyssa> IDK why they're checking only the renderer