02:19 <MoeIcenowy> anarsoul: does blob really use Z16?

02:58 <anarsoul> MoeIcenowy: I guess? we do expose it though

02:59 <anarsoul> check what format blob uses

04:16 <anarsoul> MoeIcenowy: blob uses z24s8 in http://imkreisrum.de/deqp/deqp-complete-dumps_mali400-r6p2_on-allwinner-a20/results/dEQP-GLES2.functional/fbo/dEQP-GLES2.functional.fbo.render.color_clear.tex2d_rgb_depth_component16

07:01 <MoeIcenowy> anarsoul: right

09:33 <anarsoul> rellla: I unpacked your deqp archive with "tar xjf ../mali_deqp_dump.tar.bz2 --to-command '(mkdir -p $(dirname $TAR_FILENAME); gzip > ${TAR_FILENAME}.gz)'", now I have each file compressed individually, total disk usage is 2.9G (vs 1.7G as tar and IIRC you said it's ~30G uncompressed)

09:33 <anarsoul> now I can grep it on my own machine :P

10:11 <MoeIcenowy> anarsoul: interesting trick

10:12 <MoeIcenowy> use zgrep then?

10:13 <anarsoul> MoeIcenowy: yes

10:13 <MoeIcenowy> ah maybe I should also make use of this

10:13 <MoeIcenowy> my mali dump is stored on SMR HDD

10:14 <anarsoul> or rather 'find . -exec zgrep {}\;'

10:14 <anarsoul> since zgrep doesn't support -R

10:14 <MoeIcenowy> okay then it's weird

10:15 <anarsoul> I don't want to buy new ssd only for mali dumps :)

10:15 <anarsoul> I have external hdd but it's not convenient

10:43 <rellla> anarsoul: nice trick

10:44 <rellla> btw i uploaded new dumps yesterday with recent syscall tracker...

10:45 <anarsoul> yeah, already downloaded, thanks

10:45 <rellla> though the depth_stencil_clear tests are wrong since i changed rhe deqp tests, will upload the right ones later

10:45 <rellla> they only have 1 iteration iirc

10:46 <anarsoul> enabling pixel kill breaks a lot of tests :(

10:48 <anarsoul> https://gitlab.freedesktop.org/anarsoul/mesa/-/jobs/1584231

10:54 <MoeIcenowy> maybe we need more gate?

11:59 <MoeIcenowy> but I cannot find out any extra conditions that prevents pixel killing