ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
camus has joined #panfrost
icecream95 has joined #panfrost
<icecream95> Wait... howcome Sway is spending so much time blocked at panfrost_ptr_map?
<icecream95> There must be some userspace bug here
<icecream95> Context priority not important then?
<icecream95> Hmm... we are waiting for a resource that is not even shared!
<icecream95> Maybe if I make shadowing kick in more often, things will improve?
<icecream95> Let's be totally stupid and shadow for *any* write
<icecream95> Now sway doesn't block while rendering any more, but FPS is still low
davidlt has joined #panfrost
<icecream95> The latency between scheduling and running a job is 1.5 seconds for both Sway and neverball
<icecream95> Maybe context priority would help, but ideally we don't get a queue of 1200 jobs building up in the first place
<HdkR> 1.5 second is a bit excessive. Might be hard to play neverball
davidlt has quit [Ping timeout: 480 seconds]
<icecream95> And it seems to increase at a rate of about 0.004
<icecream95> There seems to be some mechanism to "reset" that when it hits 1.7 seconds
<icecream95> What is that mechanism? Answer: BO allocation fails (because OOM), so Mesa waits for some jobs to finish so there is some free memory again
<icecream95> If alyssa was testing on a chromebook with 8 GB RAM, that explains why sway ran at four seconds per frame rather than 1.5 seconds like I'm seeing here
<icecream95> (Valhall may also allocate less memory per frame)
anholt_ has joined #panfrost
anholt has quit [Ping timeout: 480 seconds]
<icecream95> Oh does util_sparse_array use atomics? No wonder it's so slow, just a dynarray for BOs would be much better
<icecream95> util_rcu when?
<icecream95> I guess the problem is that panfrost_fence_finish returns much earlier than it should
* icecream95 looks up what DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL does
<icecream95> Something must be wrong with the fence...
<icecream95> Ohh... panfrost_batch_submit has an out_sync of 0, it shouldn't.
* icecream95 reboots after a kernel oops
<icecream95> Let me guess: If you do glFlush(); eglSwapBuffers(); then the SwapBuffers is a nop in terms of rendering
<icecream95> So then there is no GPU job to wait on, and setting an out_sync on the SwapBuffers does nothing
<icecream95> I don't think syncobjs can be attached retroactively, so then Panfrost must use a syncobj on all jobs?
<icecream95> Or... solve it in a more kbasey way and submit "soft jobs"
nlhowell has quit [Quit: WeeChat 3.5]
nlhowell has joined #panfrost
davidlt has joined #panfrost
<icecream95> Because of Gallium HUD, the batch with draws is sRGB, but the context's framebuffer state is UNORM, so they don't match and panfrost_get_batch_for_fbo needlessly creates a new batch
<icecream95> But it's possible for an application to have already flushed the batch for !HUD, so that isn't the only case that needs fixing
<icecream95> Wait no, that isn't a problem because ctx->syncobj will still be used?
<icecream95> Aha! Is the fix as simple as passing ctx->syncobj as the out_sync for every submitted batch?
<icecream95> Though maybe this could be changed to only doing it when the framebuffer is shared?
<icecream95> So instead of explcit flush => use syncobj, it would be shared framebuffer => use syncobj
<icecream95> One thing that seems concerning is that the same syncobj is now used for every frame, which I think breaks pipelining?
<icecream95> Wait that's just syncobjs being weird, things are fine
* icecream95 wonders how much performance would be lost from using soft stops to implement context priority
<icecream95> ^^ should help make things smoother when a game is rendering at just a hair over the refresh rate
<icecream95> It feels sad to have situations where sway is rendering at half the rate of neverball
rasterman has joined #panfrost
MajorBiscuit has joined #panfrost
<icecream95> Why does OpenMW look so utterly ugly on T860? Don't tell me Arm messed up on DXTn decoding
<icecream95> False alarm, it was just an "enhancement" feature on the monitor
camus has quit [Read error: Connection reset by peer]
camus has joined #panfrost
pjakobsson_ is now known as pjakobsson
Daanct12 has joined #panfrost
* icecream95 is confused about the point of input syncobjs, at least with how they are currently used in Panfrost
<icecream95> Hmm... so glFinish means that all batches which another batch (that has draws!) does not depend on must have an output syncobj set
<icecream95> Might as well just apply it to every batch then?
MajorBiscuit has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #panfrost
MajorBiscuit has quit [Quit: WeeChat 3.5]
<icecream95> 3 files changed, 17 insertions(+), 20 deletions(-)
icecream95 has quit [Quit: rcirc on GNU Emacs 28.1]
MajorBiscuit has joined #panfrost
MajorBiscuit has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #panfrost
camus has quit []
rcf has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: Leaving]
FLHerne has quit [Quit: There's a real world out here!]
FLHerne has joined #panfrost
MajorBiscuit has quit [Quit: WeeChat 3.5]
guillaume_g has quit []
floof58 has quit [Remote host closed the connection]
floof58 has joined #panfrost
derzahl has quit [Quit: auf wiedersehen]
derzahl has joined #panfrost
derzahl has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 480 seconds]
rcf has joined #panfrost
icecream95 has joined #panfrost
rasterman has quit [Quit: Gettin' stinky!]
derzahl has joined #panfrost