<anarsoul>
yuq825: nice work with multiple pending submits (or rather jobs :))
<yuq825>
thanks
<yuq825>
extra free week due to the SARI
<yuq825>
lead to the work:)
<anarsoul>
we should probably rename lima_flush_submit and lima_submit_flush since names are almost identical
<anarsoul>
yuq825: I have suspicion that lima_flush_submit() doesn't work correctly for map_transfer() if transfer is read
<yuq825>
rename lima_flush_submit to lima_flush_submit_for_bo?
<anarsoul>
so in lima_transfer_map() we call lima_flush_submit() with write = true if transfer writes to BO and with write = false if transfer reads from BO
<anarsoul>
but we need to flush any pending jobs that may write to BO if transfer reads from BO
<anarsoul>
and probably do the same if transfer writes to BO just to be safe
<anarsoul>
yuq825: something like 'lima_flush_jobs_writing_bo'?
<anarsoul>
I have strong itch to rename submit to job :)
<yuq825>
parameter write means the operation to the bo, not to the submit, when write=false, it will find submit write to the bo and flush, you may look at lima_submit_has_bo
<anarsoul>
hm
<anarsoul>
yeah, right
<yuq825>
that's fine, I can change the name to resolve ambition, but better with a last commit at once
<anarsoul>
I wonder what's going on with FBO deqp tests in CI then...
<anarsoul>
yuq825: yeah, either last or first commit should be fine
megi has quit [Ping timeout: 240 seconds]
<anarsoul>
yuq825: do you have deqp locally to check what's wrong with regressed tests or you need some help with it?
<anarsoul>
yuq825: don't we have to use "lima_flush_submit(ctx, bo, usage & PIPE_TRANSFER_READ);" in transfer_map() instead of '& PIPE_TRANSFER_WRITE'?
<anarsoul>
we want to flush jobs that write to resource if usage is PIPE_TRANSFER_READ, and flush jobs that read the resource if usage is PIPE_TRASFER_WRITE
<yuq825>
I don't have deqp setup on my side, need some time to check it, help is appreciated
<MoeIcenowy>
strange
<MoeIcenowy>
this multi submit patchset contains a UnexpectedPass
<yuq825>
anarsoul: so you mean change the parameter write's meaning to refer to the submit instead of bo?
<anarsoul>
yuq825: no, I mean that we're currently passing incorrect parameter
<anarsoul>
MoeIcenowy: likely it skips unnecessary flush that we have with single job
<anarsoul>
and thus doesn't need depth/stencil reload
<yuq825>
MoeIcenowy: I changed the clear to optional flush submit, so two calls of glClear(color) and glClear(depth) will result single submit instead of two before
<yuq825>
anarsoul: "lima_flush_submit(ctx, bo, usage & PIPE_TRANSFER_READ);" will flush both GPU read/write jobs when CPU read with PIPE_TRANSFER_READ and flush only write GPU jobs when CPU write with PIPE_TRANSFER_READ
<yuq825>
anarsoul: PIPE_TRANSFER_READ means CPU side
<anarsoul>
right
buzzmarshall has quit [Remote host closed the connection]
<anarsoul>
"dEQP-GLES2.functional.buffer.write.recreate_store.random_2" fails even with LIMA_DEBUG=singlesubmit
<anarsoul>
"lima: use lima_submit_create_stream_bo for lima_ctx_buff" is first bad commit
<anarsoul>
I've been eyeballing it for 15 mins but I don't see any obvious bugs in this commit :)
<anarsoul>
commenting out "pipe_resource_reference(&pres, NULL);" in lima_submit_create_stream_bo() fixes it
<anarsoul>
so apparently we're freeing resource to early or there's some other issue with BO ref-counting
<anarsoul>
yeah, with LIMA_DEBUG=nobocache I get gpmmu fault on read
<anarsoul>
darn
<anarsoul>
:)
Barada has joined #lima
<anarsoul>
yuq825: looks like it's some existing bug that was exposed by your MR
<anarsoul>
we're freeing BO too early
<anarsoul>
ouch
<anarsoul>
yuq825: so the issue is that we're allocating gp uniforms via u_uploader
<anarsoul>
but we allocate it and add it to submit only if it's dirty
<anarsoul>
but then we're reusing va for each draw
<anarsoul>
the issue is that BO may be gone by then
<anarsoul>
same for pp uniforms
<anarsoul>
I'd say we should probably use separate BOs for that
<anarsoul>
one from u_uploader doesn't really fit this purpose
<anarsoul>
and it makes no sense to hold 1mb BO if we haven't updated uniforms in a while
<anarsoul>
same for textures
<anarsoul>
*sigh*
<yuq825>
anarsoul: oh right, I forgot another functionality of lima_ctx_buff which keeps BO across flushs, will drop this commit
<anarsoul>
yuq825: we probably shouldn't keep BOs across flushes
<anarsoul>
pp/gp uniforms should nicely fit into 4k (min BO size)
<anarsoul>
same for texture descriptors
<anarsoul>
we should use individual BOs for them and let BO cache do its job
<anarsoul>
u_uploader uses 1M BOs and it's too wasteful to keep them around if we haven't updated uniforms
<anarsoul>
yuq825: you can drop this commit for now and I can prepare an MR that uses individual BOs for uniforms and tex descriptors
<anarsoul>
yuq825: also we don't re-add these BOs to submits even if you drop this commit
<anarsoul>
and it means that these BOs may be freed before GPU reads from them
<anarsoul>
i.e. consider following:
<anarsoul>
allocate gp_uniforms (that adds them to submit)
<anarsoul>
flush
<anarsoul>
re-use gp uniforms (doesn't add them to submit)
<anarsoul>
flush
<anarsoul>
<GPU is busy with something else and hasn't processed last job yet>
<anarsoul>
allocate new gp_uniforms, drop old BO
<anarsoul>
<GPU starts processing the job, but BO is gone => MMU fault >
<yuq825>
anarsoul: yeah, I forgot this too, that's why we add bo to submit in lima_ctx_buff_va before
<yuq825>
no in alloc
<anarsoul>
ah, I see
<anarsoul>
then yeah, dropping this commit should be fine
<anarsoul>
and should fix regressions in CI
<yuq825>
also this commit need change "lima: remove lima_ctx_buff_va submit flags"
<yuq825>
after filter out the buffer exist cross flush, we can get these two changes back
yann|work has quit [Ping timeout: 240 seconds]
yann has joined #lima
yann|work has joined #lima
niceplace has quit [Ping timeout: 260 seconds]
niceplace has joined #lima
yann|work has quit [Client Quit]
megi has joined #lima
Barada has quit [Quit: Barada]
dddddd has joined #lima
wiewo has quit [Ping timeout: 248 seconds]
wiewo has joined #lima
Barada has joined #lima
deesix has quit [Read error: Connection reset by peer]
dddddd has quit [Ping timeout: 268 seconds]
deesix has joined #lima
dddddd has joined #lima
deesix_ has joined #lima
dddddd_ has joined #lima
deesix has quit [Ping timeout: 265 seconds]
dddddd has quit [Ping timeout: 240 seconds]
dddddd_ is now known as dddddd
deesix_ is now known as deesix
buzzmarshall has joined #lima
Barada has quit [Quit: Barada]
buzzmarshall has quit [Quit: Leaving]
yuq825 has quit [Quit: Leaving.]
buzzmarshall has joined #lima
buzzmarshall has quit [Ping timeout: 260 seconds]
yann has quit [Ping timeout: 272 seconds]
marex-cloud has joined #lima
yann has joined #lima
<anarsoul>
dEQP-GLES2.functional.fbo.render.repeated_clear.tex2d_rgb passes with LIMA_DEBUG=singlejob :(
Xalius has joined #lima
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #lima
buzzmarshall has joined #lima
warpme_ has quit [Quit: Connection closed for inactivity]
warpme_ has joined #lima
Xalius has quit [Remote host closed the connection]
<anarsoul>
OK, fixed dEQP-GLES2.functional.fbo.render.repeated_clear.tex2d_rgb and dEQP-GLES2.functional.fbo.render.repeated_clear.tex2d_rgba
<anarsoul>
there's still flakes and failures in dEQP-GLES2.functional.fbo.render.shared_colorbuffer.*