<anarsoul>
and utgard seems to be dealing fine even with unaligned buffers
<anarsoul>
*attribute buffers
<yuq825>
interesting, I did not experiment much on the alignment before, just use 0x40 alignment as some address register don't have lower bits, but indeed not all of them
<anarsoul>
attribute descriptors and varyings descriptors have to be aligned to 0x40
<anarsoul>
so are varyings since literally anything that PP or PLBU consume need to be 0x40 aligned
<anarsoul>
likely GP can write unaligned varyings but PP won't be able to read them
<anarsoul>
since PP doesn't have varyings descriptor
yuq825 has quit [Remote host closed the connection]
Barada has joined #lima
smaeul has quit [Ping timeout: 260 seconds]
smaeul has joined #lima
smaeul has quit [Ping timeout: 272 seconds]
smaeul has joined #lima
yuq825 has joined #lima
Barada has quit [Quit: Barada]
Barada has joined #lima
<rellla>
anarsoul: it was an A10
<anarsoul>
yet it's mali400
<anarsoul>
and 32-bit
<rellla>
i can see if my H3 is easy to setup and try it there, too.
<anarsoul>
rellla: it's intermittent failure and it's hard to catch
<yuq825>
then I revert it due to the implementation is too complicated and can overflow PLB and heap
<yuq825>
this is for the case: draw -> flush -> display -> draw -> flush -> display without clear
<rellla>
ah ok. what is the advantage of that implementation then?
<yuq825>
blob will save the previous PLB and GP PLB buffer when flush, then reuse with new draw command
monstr has joined #lima
<rellla>
which increases performance but is not necessary to get things run?
<yuq825>
this can prevent reload the FB if the draw commands are simple
<yuq825>
and can keep the depth order
abordado has joined #lima
smaeul has joined #lima
xdarklight has joined #lima
zombah has joined #lima
<yuq825>
but can overflow the PLB and GP PLB if application does not clear and always do flush
<rellla>
who decides when mali should go this way?
<yuq825>
the OGL/EGL API
<yuq825>
if user call glFlush, lima_pipe_flush has flags=0
<yuq825>
if user call eglSwapBuffer, lima_pipe_flush has flag=PIPE_FLUSH_END_OF_FRAME
<yuq825>
another thing is if user has call glClear in this draw
<rellla>
so glFlush saves the state, eglSwapBuffer doesn't?
<yuq825>
yeah
<rellla>
is it worth to pick that up again then?
<yuq825>
with glFlush, you can see 0xa0000107 do the save and 0x90000107 do the restore
<rellla>
yes, found that
<yuq825>
yeah, if we can figure out the overflow handling
<rellla>
i didn't get still, what can overflow :/
<yuq825>
and for correctness: one draw with glFlush, then another draw, with the FB reload way, the depth info is gone, with the save/restore way, I think it's kept
<yuq825>
if I remember correctly, PLBU will save the previous draw's commands in the PLB, then add new draw's commands, one PLB block is 512B, so there's limit on the commands can be appended
<yuq825>
more accurately, not draw commands, just draw commands' PLB output
<yuq825>
in the overflow case, maybe heap buffer is used, but heap buffer is also limited size
<rellla>
the size of PLB block is hard limited?
<yuq825>
it can go up, maybe 4096 max
<rellla>
so we can try to dynamically allocate it?
<yuq825>
then you need a way to know when to realloc it and how
<yuq825>
also if 4096 is enough
<yuq825>
maybe an interrupt like the LIMA_GP_IRQ_PLBU_OUT_OF_MEM