02:17 <anarsoul> yuq825: hi

02:17 <yuq825> hi, here

02:21 <anarsoul> yuq825: I poked ppir a bit today and I think it would be nice to remodel it after nir

02:24 <anarsoul> I have strong suspicion that it was modelled after nir initially but then diverged :)

02:24 <yuq825> you mean refine ppir to be nir like?

02:24 <anarsoul> yeah, at least API

02:25 <anarsoul> currently we're managing successors/predecessors lists manually anywhere where we create ppir nodes

02:26 <anarsoul> it's quite cumbersome and error prone

02:27 <yuq825> Conner write ppir (in his stand alone compiler) first, then write nir, I get in the middle, they have some similarity indeed

02:28 <yuq825> same source

02:28 <yuq825> I'm also not satisfied with current ppir implementation

02:30 <yuq825> so refine it is welcome as can satisfy our needs

14:33 <rellla> enunes: https://gitlab.freedesktop.org/rellla/mesa/commits/ppir_fddxy_rebased is the branch with my actual code. the piglit result is the same - with and without the last commit which introduces the extra movs: http://imkreisrum.de/piglit/glsl-derivs/

14:34 <rellla> for now i have no clue, how to make the 2 tests pass.

14:34 <rellla> would be cool, if someone with a blob setup can check, if these 2 tests pass with the blob!?

14:41 <enunes> rellla: that piglit summary doesn't have the patch that introduces the movs, right?

14:42 <enunes> I don't see any movs inserted in glsl-derivs-abs-sign

14:42 <rellla> glsl-derivs is with the movs, glsl-derivs_wo is without

14:43 <rellla> there are 2 tests in the summary

14:43 <enunes> ah ok

14:43 <rellla> corresponding with HEAD and HEAD^1

14:59 <enunes> rellla: can't spot an obvious bug, two things that call my attention are why is it using .xy when we are only dealing with scalars (num_components should be 1 and write_mask 0x01?), and in the last dfdy the negative source switches from src 0 to src 1 as it is re-negated in the mov, does that work or is it mandatory to have the negative in dfdy?

14:59 <enunes> looking at glsl-derivs-abs-sign

15:01 <enunes> mandatory I mean, first src negative and second one positive

15:03 <enunes> if the second soruce is the one that must be negative then I think it is expected though

15:21 <rellla> enunes: it has to be the second, our codegen and disasm differs from what https://github.com/cwabbott0/mali-isa-docs/blob/master/Utgard-PP.md says because of the reversed numbering.

15:22 <rellla> changing the neg modifier makes all tests fail.

15:23 <rellla> regarding the write_mask i did many tests ended up with this version. we cannot hardcode it to 1 and 0x01, can't we?

15:24 <enunes> rellla: we shouldn't have to, and I think it's unlikely to be the reason for why it's failing, but it got me curious as to why it ended up with 2 components or that write mask

15:25 <rellla> i struggled with swizzles and write_mask and therefore added the commented ppir_debug's to see whats happening...

15:26 <enunes> for example that means that dfdx is arriving there with alu->src[0].ssa->num_components == 2? I wonder if that's correct

15:27 <rellla> wait a minute...

15:31 <rellla> testing it with debug enabled, but yes, num_components should be 2 because of the vec2 varying load.v $1.xy 0.xy

15:31 <cwabbott> rellla: i'd recommend reading https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx9-graphics-reference-asm-ps-registers-modifiers-source-register-swizzling and https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx9-graphics-reference-asm-ps-registers-modifiers-write-mask to understand what those mean

15:32 <rellla> cwabbott: thanks

15:33 <rellla> enunes: this is with ppir_debug commented out http://imkreisrum.de/piglit/glsl-derivs6/glsl-derivs_2/shaders@glsl-derivs-abs-sign.html

15:33 <cwabbott> the optimal thing to do kinda depends, but if you want to do something simple, you can replicate the swizzle and writemask in the move, then set the derivative swizzle to the identity

15:34 <cwabbott> and then the temporary register has the same number of components as the destination register

15:47 <rellla> imho the implementation can be optimized, but the remaining difference in the values seems to be another issue for me...

15:50 <enunes> it's not only for optimization, I would try to hardcode those to 1 to see if it makes any difference if it's a quick test

16:00 <rellla> enunes: hardcoding to 1 makes it more worse: http://imkreisrum.de/piglit/glsl-derivs7/glsl-derivs_4/shaders@glsl-derivs-abs-sign.html the last mov and dFdy is definitely wrong

16:01 <rellla> but i wonder, why the other tests also fail, though they shouldn't go through the if {}

16:02 <enunes> yeah with the hardcode some swizzle seems wrong because the mov writes to x and the last dfdy uses y

16:02 <rellla> time to make a break i guess :)

16:03 <rellla> if anybody has a hint in the meantime, you're welcome :p