02:18anarsoul: 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
02:23anarsoul: 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 :)
04:56anarsoul: well, CI passed and there is even an unexpected passed test in piglit
05:10anarsoul: https://gist.github.com/anarsoul/e8c25141efd349044b98da8c4f1a31c5
09:59enunes: anarsoul: cool, seems like a good idea and if it even saves some instructions I guess we should go for it
10:03enunes: 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
17:30anarsoul: enunes: yeah, multiply/add are not the only operations, so we cannot get rid of it
20:13anarsoul: I also implemented atan2 in ppir (or rather in nir and passed it to ppir) and I'm hitting a dependency tracking issue
20:16anarsoul: something's not right with read-after-write register deps for movs
20:19anarsoul: s/atan2/atan and atan2
20:25anarsoul: ooh, I get it. And I don't understand why we don't see more failures due to this bug.
20:25anarsoul: if we have something like:
20:28anarsoul: 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
20:29anarsoul: that's not good.
21:00anarsoul: hm, nevermind, it might be some issue with atan_pt2 on my side :)
22:27enunes: anarsoul: nice to see some activity in there :)
22:28anarsoul: :)
22:29enunes: I'm currently on vacation between trips so I won't be too active in the next couple of weeks
22:30enunes: just wanted to get CI back running before going again
22:31anarsoul: was there any issues with CI?
22:31anarsoul: s/was/were
22:33anarsoul: 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
22:33enunes: 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
22:34anarsoul: I see, I've been using CI to test my changes, so I guess I chose good time to do that :)
22:34enunes: yes in fact it only went back on this week
22:36enunes: there is also this regression to be looked into https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33053
22:37enunes: 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
22:39anarsoul: we'll probably have to summon cwabbott to fix it :)
22:41anarsoul: enunes: any comments on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33313 if you've got some time to review it?
22:42enunes: 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
22:43enunes: FFMA looks fine I guess no objections
22:44anarsoul: 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)
22:45enunes: there is already a MR to move the pass to broadcom, so the first part will probably not happen anymore
22:47anarsoul: I see
22:51enunes: atan2 looks good with the opt algebraic implementation
22:57anarsoul: atan shader-db results: https://gist.github.com/anarsoul/d612c2b245b9cc8f6dd4bd4b205ded7d
22:58anarsoul: it increases spills in one shader, since atan requires a whole vec4 (it doesn't work with vec3)
22:58anarsoul: well, it does, but if vec3 is aligned, so essentially a vec4
23:25anarsoul: hm, somehow atan got into gpir even though it should have been lowered :)
23:33anarsoul: and no regressions other than that