05:38 <anarsoul> dual source blending is out for review: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13873

05:38 <anarsoul> next thing to implement is instancing :) we can definitely do it more efficiently than an app

05:40 <anarsoul> idea is to try using stride = 0 for divisor = 0

05:40 <anarsoul> for attributes

05:42 <anarsoul> or rather stride = 0 for divisor != 0

05:44 <anarsoul> so idea is following: for each instance: setup vertex shader for 1 instance, for divisor != 0 set stride for attributes to 0 and adjust attribute pointer according to the instance, so it doesn't advance, add gl_VertexID and gl_InstanceID built-in attributes, offset outputs for each instance

05:45 <anarsoul> that's for vs and plbu

05:45 <anarsoul> since attributes buffers will be essentially the same (or very similar) for every instance it should have good cache-hit rate

05:46 <anarsoul> for fs we can just use concatenated vs output as input :)

05:50 <anarsoul> benefits: it'll save some memory and memory bandwidth (once L2 cache is populated)

07:43 <rellla> anarsoul: great, the unknown bits become less :)

07:56 <rellla> i'm chasing after the 4 deqp bias fails, but i could only make them pass when setting the bit i mentioned. but as you said, we should not set it, as long as we know, what it does.

07:59 <rellla> i wonder, why dEQP-GLES2.functional.shaders.texture_functions.fragment.texture2dproj_vec3_bias passed before. i couldn't find any critical change in how nir/ppir handles it yet. except that we don't lower anymore...

08:00 <rellla> ah, there are 3 bias fails, the cube ones pass.

10:24 <rellla> https://gitlab.freedesktop.org/rellla/mali-isa-docs/-/commit/5d8683993d7e50cd12123b6d2217d85ae2854cac

10:25 <rellla> i feel like i want to write down, what we know ;) rsw, plb, texture desc, vs ...

17:29 <anarsoul> rellla: it passed because it loaded coords from a register

17:51 <jernej> anarsoul: Is this still true? "Some tests that pass with Lima fail on Mali and vice versa." (from mesa docs)

17:51 <anarsoul> jernej: honestly, I didn't check

17:51 <anarsoul> maybe?

17:51 <rellla> anarsoul: oh, i remember you told me already

17:51 <anarsoul> we have more passing tests than blob

17:51 <anarsoul> and more features

17:51 <anarsoul> I think the only missing feature is MSAA

17:51 <jernej> don't worry, just curious

17:53 <rellla> jernej: lima http://lima.imkreisrum.de/deqp/lima_lima-fragdepth_rebased..ffbad81.main..ac7c832.head/

17:54 <rellla> mali: http://imkreisrum.de/deqp/deqp-complete-dumps_mali400-r7p0_on-allwinner-a20/

17:54 <rellla> yeah, lima has more features

17:57 <jernej> lima fail list is pretty short

17:59 <anarsoul> I have quite ambitious plans to get alacritty working on lima (not that I need it badly, just doing it for fun)

17:59 <anarsoul> with dual source blended implemented, the only missing part is instancing

17:59 <anarsoul> hw doesn't have instancing, but we can emulate it in driver, and do it more efficiently than app

18:05 <anarsoul> rellla: I wonder if dEQP-GLES2.functional.texture.mipmap.cube.* fails because we have seamless cubemap rather than regular

18:05 <anarsoul> no idea how to check it though :)

18:05 <anarsoul> expose the cap and try with piglit? it should have tests for seamless cubemap

18:06 <anarsoul> surprisingly, PP has a lot of GLES-3.0 features (unlike GP), so maybe it supports only seamless cubemaps like GLES-3.0 GPUs?

18:15 <anarsoul> enunes: how the move went?

19:07 <enunes> anarsoul: it was successful, but still lots of work to do :) assemble and set up things again

19:24 <anarsoul> enunes: great :)

19:33 <anarsoul> rellla: enunes: here's some pseudo-code on how we can implement instancing in lima: https://gist.github.com/anarsoul/487deadc4253e52301d36235ba766d7d