08:48 <narmstrong> Lyude: HdkR: sorry the u-boot binary and command to flash was wrong for the N2: `curl -L https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/u-boot.bin.odroid-n2_2019.07-rc3-00022-g47bebaa4a3.gz | zcat | sudo dd of=/dev/mmcblk0 conv=fsync,notrunc bs=512 seek=1`

09:16 <tomeu> alyssa: I think I will need your help with the blend regressions on the RK3288

09:16 <tomeu> valgrind doesn't show anything suspicious

09:17 <tomeu> I think it could be some state that leaks from one test to the other, but it's non-deterministic

09:17 <tomeu> but I have dumped shaders and cmdstream, and I don't see any differences

09:18 <tomeu> other than pointers and offsets: http://paste.debian.net/1087819/

09:18 <tomeu> so I guess it could be some state in descriptors that we don't know about, so they aren't traced

09:20 <tomeu> alyssa: in the meantime, probably we should blacklist all those blend tests, as otherwise we cannot get a green run on rk3288

09:24 <HdkR> narmstrong: I see

11:29 <tomeu> alyssa: I think this is interesting: https://people.collabora.com/~tomeu/TestResults.xml

11:29 <tomeu> 3 of the 5 failures we seem to fail always, and with quite clear problems

11:29 <tomeu> but dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.reverse_subtract_src_alpha_one_minus_constant_alpha and dEQP-GLES2.functional.fragment_ops.blend.equation_src_func_dst_func.reverse_subtract_constant_color_dst_alpha are flip-flops

11:30 <tomeu> and you can see that the error mask is all green

11:30 <tomeu> or at least it looks like that to my eyes

11:30 <tomeu> so I'm starting to wonder if the problem isn't elsewhere, maybe in deqp

11:32 <tomeu> oh, wait I see now the mismatched pixel

11:33 <tomeu> in both cases it's at the border

13:30 <shadeslayer[m]> alyssa: any thoughts on how to port this https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/panfrost/pan_context.c#L1410

13:30 <shadeslayer[m]> because we got rid of vertex_jobs

13:54 <alyssa> tomeu: At the border, eh?

13:55 <tomeu> yep, one at the top, and the other at the right (in that given run I uploaded)

13:55 <alyssa> Grrr I really want to just fix this right :p

14:14 <alyssa> Dang, I can't believe that just worked!

14:14 <alyssa> (Famous last words)

15:00 <shadeslayer[m]> <shadeslayer[m] "because we got rid of vertex_job"> Maybe we need to keep a track of the first and last tiler/vertex jobs?

15:00 <shadeslayer[m]> alyssa: tomeu ^^

15:00 <alyssa> shadeslayer[m]: Probably

15:02 <shadeslayer[m]> ok, I guess 4 variables are better than 2 linked lists

15:04 <alyssa> shadeslayer[m]: Probably :)

15:32 <shadeslayer[m]> alyssa: do you reckon I can add getter's/setter's for that in pan_job

15:32 <shadeslayer[m]> and somehow it'd be nice to make the first tiler/vertex const after I've set it

16:04 <shadeslayer[m]> ugh, I hate this code http://sprunge.us/IQ8sef

17:05 <alyssa> pan_tiler.c code is on the list, hot off the press :)

17:05 <alyssa> Truly one of the more annoying things I've worked on, but admittedly it's rewaridng

19:10 <urjaman> re war ding