ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
<anarsoul>
enunes: I experimented with passing nir_op_ffma to ppir backend, if it's translated in ppir it essentially allows to insert mul and add node into a single instruction and use a pipeline reg
<anarsoul>
it saves an instruction here and there, but it breaks ppir really badly in all the corner cases so I'm not really sure if it's worth pursing further :)
<anarsoul>
well, CI passed and there is even an unexpected passed test in piglit
jernej has quit [Remote host closed the connection]
chewitt has quit [Ping timeout: 480 seconds]
chewitt has joined #lima
<enunes>
anarsoul: cool, seems like a good idea and if it even saves some instructions I guess we should go for it
<enunes>
anarsoul: we still cant get rid of the current alu combine pass in the backend right? it is very confusing to follow from what I remember, I wonder if with this it becomes less relevant
<anarsoul>
enunes: yeah, multiply/add are not the only operations, so we cannot get rid of it
chewitt has quit [Quit: Zzz..]
<anarsoul>
I also implemented atan2 in ppir (or rather in nir and passed it to ppir) and I'm hitting a dependency tracking issue
<anarsoul>
something's not right with read-after-write register deps for movs
<anarsoul>
s/atan2/atan and atan2
<anarsoul>
ooh, I get it. And I don't understand why we don't see more failures due to this bug.
<anarsoul>
if we have something like:
<anarsoul>
ssa1 = atan2_pt1(x, y); reg87.yz = mov ssa1.yz; reg87.x = mul ssa1.x, ssa1.y; ssa2 = atan_pt2(reg87) it seems like ssa2 gets a dependency only on a single write of reg87
<anarsoul>
that's not good.
<anarsoul>
hm, nevermind, it might be some issue with atan_pt2 on my side :)
<enunes>
anarsoul: nice to see some activity in there :)
<anarsoul>
:)
<enunes>
I'm currently on vacation between trips so I won't be too active in the next couple of weeks
<enunes>
just wanted to get CI back running before going again
<anarsoul>
was there any issues with CI?
<anarsoul>
s/was/were
<anarsoul>
to be honest, I'm not planning to do a lot about lima either, just picking up some stuff that I worked on a few years ago
<enunes>
it was off since the end of last year, I had some issues with conectivity and decided to change ISP, also upgraded the connection in the process
<anarsoul>
I see, I've been using CI to test my changes, so I guess I chose good time to do that :)
<enunes>
yes in fact it only went back on this week
<enunes>
I guess it might go away with the MR which moves the pass to broadcom only but apparently there is another underlying problem in the vertex shader compiler there
<anarsoul>
we'll probably have to summon cwabbott to fix it :)
<enunes>
well I thought if the whole design of it depends on that sort of ordering I thought we might just have some pass which reorders stuff the way gpir will like it... might be easier than going through the whole dependency ordering part of it
<enunes>
FFMA looks fine I guess no objections
<anarsoul>
I'm not sure how efficient it would be to put the writes to the end of the shader (which was done as a workaround for vc4!) and then back where gpir likes it (for gpir workaround)
<enunes>
there is already a MR to move the pass to broadcom, so the first part will probably not happen anymore
<anarsoul>
I see
<enunes>
atan2 looks good with the opt algebraic implementation