<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?
<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
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?
<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)
<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