<anarsoul>
enunes: technically it's not a regression, it just exposes a bug in gpir
dddddd has quit [Remote host closed the connection]
Barada has joined #lima
Barada has quit [Quit: Barada]
Barada has joined #lima
Barada has quit [Quit: Barada]
kaspter has quit [Quit: kaspter]
kaspter has joined #lima
tlwoerner has quit [Ping timeout: 240 seconds]
tlwoerner has joined #lima
BenG83 has joined #lima
Barada has joined #lima
Barada has quit [Quit: Barada]
dddddd has joined #lima
Rondom has quit [Remote host closed the connection]
<rellla>
enunes: it's dEQP-GLES2.functional.shaders.loops.while_constant_iterations.nested_sequence_vertex which triggers the following kernel error:
<rellla>
Dec 30 12:31:53 opipc2 kernel: [953644.067375] [drm:lima_sched_timedout_job [lima]] *ERROR* lima job timeout
<rellla>
Dec 30 12:31:53 opipc2 kernel: [953644.074304] lima 1e80000.gpu: gp task error int_state=0 status=8a
<rellla>
all following tests fail...
<enunes>
rellla: hmm ok, what I wonder next is which vs setting of that patch exposes the bug, if it's the const buffer size ones or loop unrolling
<enunes>
and since it's likely not an introduced bug but probably exposing an existing bug, if we should revert that particular setting or not
<rellla>
enunes: i can try to play with the values and see which one it is
<rellla>
enunes: https://pastebin.com/raw/GuQhJvwb that one fixes at least this test again. better said, this is the reason, why the bug is exposed :p
<rellla>
so if we are sure, that it's a VS bug, we should keep the patch and adapt the skips and fails lists. the better solution would be to fix the bug now :)
<enunes>
hmm yeah thats bad, for that one I think it's even more likely it's an existing bug
<enunes>
if you have time, could you try to rebase 00:51 [ _whitelogger ] [ cp- ] [ embed-3d ] [ lvrp16 ] [ Net147 ] [ sphalerite ]
<rellla>
enunes: yeah, i will only test that one for now
armessia has joined #lima
<rellla>
enunes: the test passes with lima-gpir-branch-opt-v4 on top of current master
megi has joined #lima
<rellla>
i will run a full test suite now.
<enunes>
rellla: well that is helpful, thanks a lot for testing it
<rellla>
enunes: i think, we should keep the caps patch as is for now and i will sort out my skips and fails list
<enunes>
so we have to decide, I suppose we can just skip that test for now, any opinion anarsoul ?
megi has quit [Ping timeout: 265 seconds]
<rellla>
enunes: i'll give up with the full run with cwabbotts patches. i get too much crashes to sort out, so i think i'll wait until it's finished and go ahead with master
<enunes>
fair enough
megi has joined #lima
<rellla>
enunes: i noticed, that dEQP-GLES2.functional.shaders.loops.while_dynamic_iterations.nested_sequence_vertex was already on my skips list, because it also crashed the driver. without your patches :)
<rellla>
so both, *.while_[dynamic|constant]_iterations.nested_sequence.vertex crash the driver.
danqo has quit [Remote host closed the connection]
<MoeIcenowy>
rellla: what kernel are you on?
<MoeIcenowy>
we should prevent the driver from being crashed
<MoeIcenowy>
it's part of userspace-kernelspace isolation
<anarsoul>
enunes: yeah, I think we can skip it for now
<anarsoul>
unless you want to dive into gpir compiler :)
<anarsoul>
rellla: there's nothing suspicious in disassembly
<anarsoul>
so it must be something with command stream
<rellla>
MoeIcenowy: Linux opipc2 5.4.0-11681-g63de37476ebd #13 SMP PREEMPT Wed Dec 4 10:59:26 CET 2019 aarch64 GNU/Linux
<rellla>
iirc i have all relevant lima commits included
<anarsoul>
rellla: so color is taken from varying, sounds like we have some issue with varying setup
<anarsoul>
maybe varying pointer requires some extra alignment?
<anarsoul>
basically my commit shifted varyings by gl_Position size (that's 16 * number of vertices)
<anarsoul>
it's still aligned to 64 bytes though
<rellla>
anarsoul: at least the second value of the varying besides the address is different: 0x0000400f for mali, 0x00008002 in lima. so a few bits of our lima_update_varying differ in the end
<anarsoul>
rellla: likely blob uses different varying format
<anarsoul>
I assume it's fp16
<anarsoul>
i.e. 0x8002 is vec4 fp32, 0x400f vec4 fp16
<rellla>
ok
<anarsoul>
value for varying is taken from attribute
<anarsoul>
so it either reads attributes incorrectly
<anarsoul>
or writes varyings incorrectly
<rellla>
apart from the varying, doesn't the viewport smell suspicious, too?
<anarsoul>
not really
<rellla>
anarsoul: i did a new dump with current master http://imkreisrum.de/deqp/index_array.array_lima.new/ . i don't know, why some things are different now, the second value of the attributes' info for example...
<anarsoul>
0x10095440, 0x00006002, 0x10095a80, 0x00004001 in blob
<anarsoul>
0x00496040, 0x00004001, 0x00496830, 0x00006002 in lima
<anarsoul>
likely it just reordered attributes
warpme_ has quit [Quit: Connection closed for inactivity]
<rellla>
i still don't get, why mali has 3 DRAWs in VS CMD, with num 24, 183 and 27 and one /* DRAW_ARRAYS: count: 129, start: 0, mode: 3 (0x3) */ in the plbu afterwards
<anarsoul>
likely wallpapering?
<rellla>
shouldn't plbu and vs draw nums correspond to eachother?