ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
<enunes>
I agree but as I posted there, even if replaying the trace doesn't crash, it renders some garbage, from what I have seen so far basically due to the same bug
<anarsoul>
interesting
<anarsoul>
does it actually use 4096x4096 textures?
<enunes>
now I noticed that the first is a blit, and running with LIMA_DEBUG=noblit seems to avoid the bug as well, so it might be something with the lima blitter, the scissor is not matching in that blit too
<anarsoul>
format is LIMA_TEXEL_FORMAT_RGBA_8888
<anarsoul>
enunes: it might be a missing dependency somewhere?
<anarsoul>
if it gets fixed by limiting width, the job is completed faster and its resources aren't released while it's still in fly
<enunes>
with LIMA_DEBUG=noblit it can even run with regular 4096 max texture, and the blit job should take longer, so if anything it needs to be related to the blit cmd, no?
<enunes>
is it ok that the scissor is 2048 and the blit is 4096?
<anarsoul>
enunes: I don't see why not?
<anarsoul>
I don't see VS or PLBU commands in the dump
<enunes>
we have a comment saying /* Scissored blit isn't implemented yet */ and it should fall back to u_blitter but seems like it may be continuing in some case and miscalculating the scissor cmd for the blit
<anarsoul>
scissor and viewport should be clamped by fb size though
<anarsoul>
enunes: it uses scissor for handling dst box
<anarsoul>
enunes: can you post complete dump?
<enunes>
its hundreds of frames, the first one I posted is complete, the second I cropped because pastebin complained it's too big, but I think the rest is uninteresting
<anarsoul>
I see
<anarsoul>
I suspect some dependency is not handled in lima_blit
<anarsoul>
these are hard to debug
prahal[m]1 has joined #lima
<anarsoul>
enunes: looks like 0x6186000 VA of 4096x32 texture from 2nd paste is referenced in pp frame in the 1st
<anarsoul>
I assume it's the same context, and lima_do_blit does add the job to ctx->write_jobs
<enunes>
anarsoul: I still think it's something simpler than that... just hacking the blit scissor size to follow size of the fb seems to avoid the crash as well
<anarsoul>
enunes: but it likely breaks the blitter
<anarsoul>
:)
<anarsoul>
changing scissor size changes timings, so I'd still bet on dependency issue
Leopold_ has quit [Read error: Connection reset by peer]
Leopold has joined #lima
<anarsoul>
enunes: out of curiosity, does it work correctly if you make jobs synchronous?
<anarsoul>
if you enable dumping, it should be synchronous
<anarsoul>
so do you see the issue with LIMA_DEBUG=dump?
<anarsoul>
btw, flushing blit job immediately seems to be suboptimal
<anarsoul>
but I don't really remember why I did it like that
<anarsoul>
in theory dropping lima_do_job() from lima_do_blit() should work just fine
<enunes>
anarsoul: singlejob or dump seem to make no difference, reproduces with or without
<anarsoul>
then it's likely not a race
<enunes>
interestingly nobocache makes it crash on my system too rather than just rendering garbage
<anarsoul>
hmm
<anarsoul>
sounds like a missing dep?
<anarsoul>
i.e. some job is using a BO, but it wasn't added to a job
<anarsoul>
but it should give you a clue on what it's attempting to reuse
<anarsoul>
if it's a gpu crash just compare fault VA with dump