<anarsoul>
any ideas how to fix it more efficiently?
<anarsoul>
btw with your MR I get nice FPS boost in q3a, it's unfortunate that it's not stable
<yuq825>
1 is true, 2 I do add cbuf and flush in lima_job_get and lima_update_job_wb
<anarsoul>
yuq825: 2 can be way to early
<anarsoul>
we need to flush dependencies before we're flushing current job
<anarsoul>
not earlier
<yuq825>
then maybe save a list for textures, vc4 and v3d have multi lists which maybe for this purpose
<anarsoul>
yuq825: yeah, probably
<anarsoul>
so something like lima_job_add_texture()?
<yuq825>
I suggest fix 1 and other problems first, and left the further optimization in next MR
<yuq825>
I prefer to move if (ctx->dirty & LIMA_CONTEXT_DIRTY_TEXTURES) into lima_update_textures
<anarsoul>
sounds good
<anarsoul>
yuq825: do you want me to fix it or you prefer to do it yourself?
<yuq825>
thanks, I'm doing it now, will send out soon
<anarsoul>
yuq825: btw flushing textures later is not an optimization
<yuq825>
why?
<anarsoul>
is there a guarantee that there won't be another job that writes to the texture before we do flush?
<anarsoul>
well, at least for reload we have to do it at flush time
<anarsoul>
consider we have 2 FBOs with the same cbuf
<yuq825>
lima_job_get will check if cbuf is read/write by other job, then flush them
<anarsoul>
yuq825: but it can be too early
<yuq825>
it can be delayed, but is correct, and lima_job_get will be called only in draw/clear functions, not on framebuffer create, so delayed a little
<anarsoul>
but occasionally fail with multiple jobs
chewitt has joined #lima
<anarsoul>
yuq825: I'd suggest moving "lima: always add texture bo to submit" to the beginning of your MR, or at least before commit that enables multijob
<anarsoul>
otherwise it may hurt bisectability
<yuq825>
anarsoul: I suppose we need it anyway
<anarsoul>
btw I can make an apitrace for you for failed tests if you want to debug them
<anarsoul>
note that they all are "dEQP-GLES2.functional.fbo.render.shared_colorbuffer.*", so likely they have common issue
<yuq825>
I have a x86 build now
<yuq825>
won't we need to add texture bo to submit without multi job?
<anarsoul>
yuq825: we do need that, but it just somehow works even without that :)
<anarsoul>
probably because all the jobs are serialized
buzzmarshall has quit [Remote host closed the connection]
<yuq825>
but texture may be freed before submit is done, I don't find any place to prevent it
chewitt has quit [Quit: Zzz..]
<yuq825>
so I don't think it will hurt bisect
<anarsoul>
fair enough
<yuq825>
btw. I find some gp error irq in the gitlab test log, seems it exist before this MR, like heap mem not enough, so the test platform's kernel doesn't have the grow heap support?
<anarsoul>
yuq825: yeah, it's 5.5
<anarsoul>
I attached apitrace of one of failing tests to the MR
<yuq825>
OK, I would be surprised if 16MB is not enough
<yuq825>
thanks
<anarsoul>
yuq825: was growing heap merged into 5.6?
<yuq825>
not yet
yuq825 has quit [Ping timeout: 268 seconds]
champagneg has quit [Ping timeout: 268 seconds]
yuq825 has joined #lima
dddddd has quit [Ping timeout: 240 seconds]
chewitt has joined #lima
chewitt has quit [Quit: Zzz..]
megi has quit [Ping timeout: 272 seconds]
chewitt has joined #lima
yuq825 has quit [Quit: Leaving.]
chewitt has quit [Quit: Zzz..]
chewitt has joined #lima
yuq825 has joined #lima
chewitt has quit [Quit: Zzz..]
chewitt has joined #lima
yann has quit [Ping timeout: 240 seconds]
Xalius has joined #lima
megi has joined #lima
yann has joined #lima
Xalius has quit [Quit: Leaving]
yuq825 has quit [Ping timeout: 272 seconds]
yuq825 has joined #lima
yuq825 has quit [Ping timeout: 272 seconds]
dddddd has joined #lima
yann has quit [Ping timeout: 240 seconds]
champagneg has joined #lima
yann has joined #lima
_whitelogger has joined #lima
yann has quit [Read error: Connection reset by peer]
yann has joined #lima
chewitt has quit [Read error: Connection reset by peer]