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
<bloom>
I don't want to be the reason someone's not sleeping!
<bloom>
Alright. Sure. Let me get a bite to eat first. 20 minutes, then? (Starting at ~10:30am?)
<jix>
works for me, it's afternoon here, so me not sleeping is probably a good thing ^^
<chadmed>
bloom: hence my dilemma, its almost 1am so i should sleep, but i also want to watch
<bloom>
:F
<bloom>
Just getting setu now
<bloom>
on air
<jix>
can hear you :)
<jix>
I've heard that even recent-ish discrete desktop GPUs use tiling (need to dig out the blog post which had some code to actually demonstrate that)
<jix>
bloom: do you need to exclude already freed entries in track_free?
<jix>
bloom: yeah your change of zeroing everything was what I was thinking of when I wrote that
<jix>
bloom: I think the stream freezed
<jix>
audio is still fine but it only shows the broken demo
<jix>
yeah can hear you
<bloom>
should be back now
<jix>
yeah
<jix>
i wonder, are the handles at the end of the header and at the end of each entry, or are they actually at the start of each entry? (might be obvious with more context, but isn't to me)
<jix>
no still fine
<jix>
maybe that code got culled at some point ;)
choozy has joined #asahi-gpu
phiologe has joined #asahi-gpu
PhilippvK has quit [Ping timeout: 480 seconds]
<jix>
I'm a bit confused by having DIRTY_ANY defined to be a specific bit, or do you set it whenever you set another bit? (might have missed that)
<jix>
at least that's what I had expected
<jix>
wouldn't this also change the thing you were testing last?
<jix>
(I might be totaly confused though)
<jix>
ah yeah that was what I was missing, thanks :)
* bloom
wondering how dirty tracking of user uniforms was ever supposed to work...
<xerpi[m]>
Regarding this random hang/HW issue: are the CPU and GPU cache coherent? If so, only LLC or also L1/L2? Maybe you need to flush some shared stuff/descriptors up to LLC
<jix>
is the windowserver log msg just forwarding errors from kernel, or is it having an additional error when this happens?
<jix>
(I was asking because I was wondering whether the windowserver error has anything to do with how you get stuff on screen in the end (not knowing how you do that/how that works on osx), but just everything starting to fault makes sense, especially after seeing OBS hang before)
<xerpi[m]>
Let's hope this was not the issue and that the GPU also snoops the L1/L2, otherwise it will get hairy, you would also need to invalidate BOs when reading data the GPU has written..
<xerpi[m]>
Would be nice if the GPU reported some kind of error code. Maybe macOS kernel doesn't expose it to userspace, but would mmio tracing help?
<xerpi[m]>
Maybe the debug/developer macOS kernel printks a nice error message
<jix>
is there any apple code talking to the GPU that would need to be synchronized with what your mesa driver is doing? if it's not some cache issue, it seems like a race condition to me, just from the random timing and how it is affected by debug printing etc..
quarkyalice__ has quit [Ping timeout: 480 seconds]
<bloom>
jix: yes, absolutely
<bloom>
(which made me think the problem is preemption, but I can't prove that)
<jix>
I wonder if dtrace would help in figuring out when this happens
<bloom>
maybe? I' not familiar with dtrace
<jix>
me neither, but I think it should allow you to do selective system wide tracing of stuff... e.g. the IOKit calls and scheduling/preemption of threads/processes
<jix>
at least that's what I remember from when it was introduced and I was still using mac os, never did more than trying a few example dtrace scripts though... and that was ~14 years ago, so I have no idea how well it is supported today