<rellla>
we have textures at 0x10096800 and the first entry is the address of the texture descriptor -> 0x10080240
<rellla>
is it possible, that we get more addresses in the list at 0x10096800? i'm not sure i do understand that correct, but i guess we can have more addresses here, because in lima there is the "lima_tex_list_size"
<rellla>
if so, i have to implement that on top, what should be trivial though...
<rellla>
anyway, now available to debug indexed draws :)
<anarsoul>
I think we have to make sure that PLBU waits for VS to complete its draw command, then VS should wait for PLBU to complete its draw command
<anarsoul>
also looks like we pass vertex arrays and indices via PLBU commands
<anarsoul>
so VS should wait for PLBU to issue this commands before doing draw
<anarsoul>
I'm still looking into blob dumps and trying to understand it though
<anarsoul>
so I'm not sure that it's 100% correct
<rellla>
i'm running it on master now and i get massive fails with shaders.loops.* ... so my guess is, that this commit broke sth. i did not bisect it though...
<rellla>
anarsoul: about indexed draws, i think i can't look into it much earlier...
<rellla>
[647110.723640] [drm:lima_sched_timedout_job [lima]] *ERROR* lima job timeout
<rellla>
[647110.730567] lima 1e80000.gpu: gp task error int_state=0 status=8a
<rellla>
i think, this is the reason why following test fail.
<rellla>
yeah, definitely fries the driver. cancelled now...
<anarsoul>
either VS shader issue
<anarsoul>
or issue with semaphores
<anarsoul>
sounds like shader issue
<rellla>
the kernel message is with current master, not related to indexed draws