ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs - <macc24> i have been here before it was popular
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC:]
jernej has joined #panfrost
chewitt has quit [Quit: Zzz..]
nlhowell has joined #panfrost
MajorBiscuit has joined #panfrost
Major_Biscuit has joined #panfrost
camus has quit [Remote host closed the connection]
camus has joined #panfrost
MajorBiscuit has quit [Ping timeout: 480 seconds]
rasterman has joined #panfrost
guillaume_g has joined #panfrost
nlhowell has quit [Ping timeout: 480 seconds]
rkanwal has joined #panfrost
floof58 has quit [Ping timeout: 480 seconds]
icecream95 has quit [Ping timeout: 480 seconds]
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 480 seconds]
<robmur01> yeah, definitely many issues here... my results for provoking the shrinker go: lockdep warning -> use-after-free -> sleeping in atomic -> BUG running IRQ work with IRQs enabled
<robmur01> nearly a full bingo card, I think...
<HdkR> robmur01: How much do you know about making WFE sleep longer than 42 nanoseconds? Speaking of sleeping in atomic :P
rkanwal has quit [Quit: rkanwal]
rkanwal has joined #panfrost
rkanwal has quit []
<robmur01> HdkR: different sleeps... However, the nature of your question sounds like you're trying to do something very wrong ;)
rkanwal has joined #panfrost
<HdkR> robmur01: One of the wake up events uses the exclusive monitor system, which matches the x86 monitor wait system. Just that the x86 system under testing can sleep for up to 4ms without spurious wakeup
<robmur01> WFE is an "I've got nothing better to do until the next thing happens", not a precise delay instrument
<robmur01> if it wakes up "early", it's because "shit be happening, yo"
<HdkR> Yea. I think that's the problem, since WFE will wake up for significantly more events than the equivalent x86 feature :/
<robmur01> because it's not equivalent, only vaguely similar if you squint hard enough :/
<HdkR> :D
<HdkR> Sadly there isn't a nice way to get exclusive monitor status after spurious wakeup for quickly spinning back to a sleep
<robmur01> again, because "get exclusive monitor status" is not a meaningful thing in isolation and suggests that you're trying to do something doomed
<robmur01> the paradigm is: try to do something; WFE; try again
<HdkR> Yea, It's already partially doomed since I know someone is trying to use the x86 monitor solution for userspace mutex on a task thread :|
<robmur01> a job for futexes maybe?
<HdkR> Being able to stall their task thread for 4ms while waiting for monitor event to fire being doing "RT" audio tasks seems to be the goal. Lighter weight handling is their hack
<HdkR> So rough time regardless
<HdkR> I guess this is better for their SMT target system? I dunno :)
<robmur01> you know that at the very least we enable the arch timer event stream at 10KHz, right? :)
<HdkR> haha, welp
rkanwal has quit [Quit: rkanwal]
pjakobsson has quit [Remote host closed the connection]
nlhowell has joined #panfrost
nlhowell has quit [Ping timeout: 480 seconds]
floof58 has joined #panfrost
<robmur01> oh good lord, apparently since "Neoverse" we're now doubling down on daft product names :/
<robmur01> perhaps the gag is that it's almost an anagram of "it's more Mali"?
<HdkR> Immortalis sounds like a DC comics villain
<robmur01> or some RGB-LED-festooned nonsense from Razer
<HdkR> Time to get Razer to make a ARM laptop
<robmur01> particularly ironic that it'll be Outofdateis in a year... everyone knows the only truly immortal GPU is Mali-400
<HdkR> Looking forward to throwing PC game workloads at it
<anarsoul> robmur01: or 450?
<anarsoul> btw I thought that allwinner switched away from utgard
Major_Biscuit has quit [Ping timeout: 480 seconds]
karolherbst has quit [Ping timeout: 480 seconds]
greenjustin has quit [Quit: Leaving]
karolherbst has joined #panfrost
rasterman has quit [Quit: Gettin' stinky!]
icecream95 has joined #panfrost
<icecream95> "Ray Tracing on Immortalis-G715 only uses 4 percent of the shader core area". About as much as geometry shading/tessellation then?
<icecream95> "adding more native commands [to CSF]". What are non-native commands? Sequences of other commands, or calls back to the MCU?
<icecream95> So far the only non-load/store/job-execute command I've reversed with v10 CSF is ADD...
<icecream95> I wonder if it's possible to find v11 drivers yet... probably only for Android so far
<icecream95> robmur01: Maybe it's called Immortalis because you won't forget trying to do anything with it in a hurry
alyssa has joined #panfrost
<alyssa> Can we refuse to support this on name alone? Please? :-p
<icecream95> Hmm... it's an anagram of 'most ir mali'. Doesn't bode well for writing a compiler
<icecream95> Or does it mean that the ISA is close to LLVM IR?
<HdkR> Consume LLVM IR directly, but it's stuck on version 3.7
<alyssa> HdkR: DX12 has entered the chat
<alyssa> icecream95: I would like to think the ISA is the same (plus extensions for raytracing)
<HdkR> vkd3d has entered the chat.
<icecream95> alyssa: You would like to, sure
<alyssa> Ah well yes that.
<alyssa> I see no reason v11 shouldn't be v10 backwards compatible.
<alyssa> But that has literally never stopped Arm before...
<alyssa> I have a pretty good idea how this will work at an ISA level, but we'll find out.
<icecream95> Over the past few days I've been getting Panfrost to work with kbase again, in preparation for v10 where kernel support will take a while
<icecream95> I've got Wayland compositors working, but with glmark2-es2 there are a bunch of artefacts, which is fun
<alyssa> Wee
<icecream95> My evil plan is to at the same time develop backwards towards the beginning of Panfrost with kbase support etc., and also write support for newer GPU architectures
<icecream95> You will be trapped!
<alyssa> Trapped in... what?
<alyssa> A box?
<alyssa> An AABB box?
<icecream95> Midgard
<icecream95> Don't get me started on how the tiler uses AABB...
<alyssa> Re kbase not working, at a guess -- incorrect dependencies between atoms, or incorrect shareability/coherency flags on the memory allocations?
<icecream95> That shouldn't be a problem... I'm effectively using PAN_MESA_DEBUG=sync
<icecream95> And not specifying CPU caching on allocations, but that hasn't prevent problems for me in the past...
<alyssa> With v9, I had some funny issue with the tiler heap being mapped with the wrong caching flags
<alyssa> Unsure if that applies to older Mali
<icecream95> I've noticed (as Valgrind doesn't support it) that the blob uses some cache flush instructions, while I thought that only SYNC was needed
<alyssa> (v9 was the last time I wrote kbase integration code, v5 before that. I managed to skip out on Bifrost/kbase entirely, wow! :-p)
<icecream95> But this is T860, so ioctls-that-aren't-ioctls and all that fun stuff
<icecream95> I'm surprised at how easy it was to get it working with KMS
<icecream95> Time to get back to implementing the mali_buffer_sharing Wayland extension in Mesa, so the blob and Panfrost can run at the same time
<alyssa> Oh boy.
<icecream95> alyssa: How much will you hate me if I get Panfrost working well with kbase and tell everyone to run hybrid blob/Panfrost even on <v10?
<alyssa> That's not really how this works?
<alyssa> If people want to run kbase and the blob, they can do that already. They don't need us for that.
<alyssa> Broadly, upstream drivers (kernel and Mesa) are the selling point in themselves.
<alyssa> And... kbase will never be accepted upstream
<icecream95> So you're telling me that I can do that then? blob GLES + Panfrost GL...
<alyssa> It's open source code. I couldn't stop you?
alyssa has quit [Quit: leaving]