02:18 <anarsoul> CounterPillow: no vsync?

02:18 <anarsoul> you need something similar to 7b24eec754ba0f0f794ab09413dcde2585b4a84b("drm/sun4i: wait on implicit fence before display") for rockchip driver

02:19 <anarsoul> I mean drm driver

12:49 <CounterPillow> anarsoul: alright so I guess I need to write a patch, thanks for the hint! Will try to get around to doing that

14:07 <rellla> the description of the vec4 add/mul alu's write mask is misleading in https://github.com/cwabbott0/mali-isa-docs/blob/master/Utgard-PP.md

14:08 <rellla> it is linked to Varying Fetch -> "m - Mask, (0001 = float, 0011 = vec2, 0111 = vec3, 1111 = vec4)"

14:09 <rellla> which is not right imho. it should be mmmm -> wzyx !? so 0010 only writes to .y for example

14:17 <cwabbott> rellla: I think you don't understand what the "mmmm" means... it just means that those 4 bits form a bitfield called "m", and below that when it says "m - Mask" it means that m is short for Mask

14:21 <rellla> cwabbott: https://pastebin.com/9x6VRbey so let's see the vec addition alu description. we have the mmmm which is the placeholder for a 4 bit field, right?

14:22 <rellla> line 26 in the pastebin leads me to the conclusion, that only "0001 = float, 0011 = vec2, 0111 = vec3, 1111 = vec4" as values are possible

14:23 <rellla> which is not right, isn't it?

14:23 <cwabbott> no, that description is indeed a little lacking

14:24 <cwabbott> there's a better description earlier up

14:24 <rellla> for me it is like 0001 is .x, 0011 is .xy and 1010 is .yw , right?

14:24 <cwabbott> When writing to a vector register, you can specify a "write mask" or "output mask". Conceptually, all 4 components of the result are calculated, but only the components specified by the write mask are actually written to the register"

14:24 <cwabbott> yeah, that's right

14:25 <rellla> ok, fine :)

14:25 <rellla> so we have some bugs with the write mask in pp. for example:

14:25 <rellla> http://imkreisrum.de/piglit/master_fed6aa2fec3/master_fed6aa2fec3/shaders@glsl-sin.html

14:25 <cwabbott> what's tricky is that the swizzle is "expanded" so that e.g. mov r1.y r2.xyzw actually moves r2.y to r1.y

14:26 <rellla> load.u 0.x, mul.s0 $1.x ^uniform.x ^const0.x, const0 0.159180 0.000000 0.000000 0.000000

14:26 <rellla> sin.s2 $0.y $1.y

14:27 <rellla> either mul.s0 should go to .y or sin.s2 should use .x !

14:28 <cwabbott> correct :)

14:30 <rellla> the problem imho is caused by https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/lima/ir/pp/lower.c#L329 when we have to deal with exactly 1 component. then the write mask always gets "0001" which in turn always writes to .x - even if .y is needed...

14:30 <rellla> we need some swizzle_to_writemask() ...

14:39 <rellla> and https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/lima/ir/pp/lower.c#L334 also seems a bit wacky, doesn't it? it does hardcode the swizzle to .yyyy ?! I can't believe that is wanted ...

14:39 <rellla> sorry. my fault.

14:39 <rellla> it indeed is .wzyx ;)

14:40 <rellla> too much swizzles and mask for now :)