02:14 <icecream95> Wait... howcome Sway is spending so much time blocked at panfrost_ptr_map?

02:14 <icecream95> There must be some userspace bug here

02:14 <icecream95> Context priority not important then?

02:29 <icecream95> Hmm... we are waiting for a resource that is not even shared!

02:31 <icecream95> Maybe if I make shadowing kick in more often, things will improve?

02:33 <icecream95> Let's be totally stupid and shadow for *any* write

02:35 <icecream95> Now sway doesn't block while rendering any more, but FPS is still low

03:39 <icecream95> The latency between scheduling and running a job is 1.5 seconds for both Sway and neverball

03:40 <icecream95> Maybe context priority would help, but ideally we don't get a queue of 1200 jobs building up in the first place

03:52 <HdkR> 1.5 second is a bit excessive. Might be hard to play neverball

04:46 <icecream95> And it seems to increase at a rate of about 0.004

04:50 <icecream95> There seems to be some mechanism to "reset" that when it hits 1.7 seconds

04:56 <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

05:00 <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

05:01 <icecream95> (Valhall may also allocate less memory per frame)

05:22 <icecream95> Oh does util_sparse_array use atomics? No wonder it's so slow, just a dynarray for BOs would be much better

05:23 <icecream95> util_rcu when?

05:29 <icecream95> I guess the problem is that panfrost_fence_finish returns much earlier than it should

05:34 <icecream95> Something must be wrong with the fence...

05:36 <icecream95> Ohh... panfrost_batch_submit has an out_sync of 0, it shouldn't.

05:41 <icecream95> Let me guess: If you do glFlush(); eglSwapBuffers(); then the SwapBuffers is a nop in terms of rendering

05:42 <icecream95> So then there is no GPU job to wait on, and setting an out_sync on the SwapBuffers does nothing

05:44 <icecream95> I don't think syncobjs can be attached retroactively, so then Panfrost must use a syncobj on all jobs?

05:44 <icecream95> Or... solve it in a more kbasey way and submit "soft jobs"

06:22 <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

06:23 <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

06:26 <icecream95> Wait no, that isn't a problem because ctx->syncobj will still be used?

06:29 <icecream95> Aha! Is the fix as simple as passing ctx->syncobj as the out_sync for every submitted batch?

06:29 <icecream95> Though maybe this could be changed to only doing it when the framebuffer is shared?

06:30 <icecream95> So instead of explcit flush => use syncobj, it would be shared framebuffer => use syncobj

06:31 <icecream95> One thing that seems concerning is that the same syncobj is now used for every frame, which I think breaks pipelining?

06:39 <icecream95> Wait that's just syncobjs being weird, things are fine

07:25 <icecream95> ^^ should help make things smoother when a game is rendering at just a hair over the refresh rate

07:54 <icecream95> It feels sad to have situations where sway is rendering at half the rate of neverball

08:03 <icecream95> Why does OpenMW look so utterly ugly on T860? Don't tell me Arm messed up on DXTn decoding

08:11 <icecream95> False alarm, it was just an "enhancement" feature on the monitor

11:00 <icecream95> Hmm... so glFinish means that all batches which another batch (that has draws!) does not depend on must have an output syncobj set

11:01 <icecream95> Might as well just apply it to every batch then?

11:18 <icecream95> 3 files changed, 17 insertions(+), 20 deletions(-)