01:22 <enunes> anarsoul: for the sin/cos constant creation, I see that panfrost has a solution for it as its own opt_algebraic at https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/panfrost/midgard/midgard_nir_algebraic.py#L70

01:23 <enunes> we should probably move that to src/panfrost/shared and also use it

01:27 <anarsoul> yeah

01:27 <anarsoul> I'd prefer it do be "'fmul', a, 1 / math.pi" though

01:28 <enunes> yeah I thought the same

13:36 <MoeIcenowy> could lima kernel driver allocate some contingous memory for a scanout buffer?

13:40 <enunes> MoeIcenowy: no, lima used to have that but it was removed. if you need a contiguous memory buffer for scanout, it is allocated in the display driver and imported in lima

13:41 <MoeIcenowy> but on Android allocating scanout buffer is done by GPU's render node

13:41 <MoeIcenowy> if use gbm_gralloc

13:45 <enunes> that seems strange, can't you make it allocate in the display driver node?

13:48 <enunes> quite a long time ago: https://github.com/yuq/linux-lima/commit/6312f148494a9ddd2b053b915c7ab01ea738e086

13:50 <enunes> it seems that all drivers using kmsro do the same, so it surprises me that android would have such a hard requirement

13:51 <enunes> well vc4 does it differently, but I guess it doesn't have an mmu anyway

14:11 <MoeIcenowy> enunes: yes, nearly all drivers w/ kmsro fail under Android

14:11 <MoeIcenowy> because it's doing process isolation now

14:12 <MoeIcenowy> the buffer allocator is in a different process w/ display

14:35 <enunes> MoeIcenowy: I have no idea about android status so now mostly curious, did you ever have any kind of success with lima and android? is it any close to working at all?

14:54 <MoeIcenowy> no

14:58 <bshah> Hi there, so I have been debugging plasma mobile with the Lima, and with git master I had huge success overall. Although with one exception of keyboard behaving weird : namely Text items are not showing up. It is only issue keeping whole thing from being somewhat usable. : https://bshah.in/virt-keyboard-qmlscene.trace is the apitrace I captured.

15:00 <bshah> earlier i had case of gpir error : "gpir: if nir_cf_node not support" but i removed the component which caused that, and I no longer see that

17:11 <anarsoul> bshah: does it render correctly on llvmpipe with modified shader?

17:13 <bshah|matrix> anarsoul: I didn't modify the shader which was causing gpir error. I removed usage of it completely. And it works fine without yes.

19:04 <anarsoul> enunes: lima and panfrost use different scaling constants

19:05 <anarsoul> so I think it's not reasonable to move it into common pass

19:06 <enunes> anarsoul: yeah I just asked in panfrost, hadn't realized that the constant is different

19:07 <anarsoul> btw I'm almost done with it

19:07 <anarsoul> (own algebraic pass)

19:08 <enunes> cool

19:08 <enunes> I hope we can move more and more stuff to something like that

19:11 <enunes> anarsoul: I tried nir_opt_vectorize (before vec_to_scalar with the ops we want), looks like it significantly improves ppir shaders and causes no piglit regressions

19:12 <anarsoul> nice

19:14 <anarsoul> btw, I tried running q3a on lima

19:14 <enunes> https://paste.fedoraproject.org/paste/LPNjTA9Osvrtn2P9dW62tQ

19:15 <anarsoul> it's able to render menu but it's *very* slow

19:16 <enunes> cool, on X?

19:17 <anarsoul> yes

19:18 <anarsoul> we have a bottlneck somewhere

19:18 <anarsoul> it's easy to reproduce with mpv

19:18 <anarsoul> mpv stutters

19:18 <anarsoul> same with q3a

19:19 <enunes> maybe some profiling tool?

19:32 <anarsoul> yeah, will try

19:41 <piggz_> enunes: lo ... i started bisecting, and got stuck......

19:41 <piggz_> telling bisect that mesa-19.1.3 was good, and master was bad

19:41 <piggz_> after about 2 bisects, it gives up and says the merge base is bad

19:51 <enunes> piggz_: hmm I don't remember what was the bisect about? I think 19.1 would be easier to try the bisect on. we didn't backport anything to a stable branch as far as I know, so it doesn't make much sense that a stable branch fixes a bug in lima I guess...

20:24 <anarsoul> enunes: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1586

20:24 <anarsoul> rellla: ^^

20:25 <anarsoul> I guess it deprecates your https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1536

20:28 <anarsoul> I verified that glsl-sin and glsl-cos now pass

21:12 <rellla> anarsoul: yeah, noticed it already. much more clearer implementation ;)

21:15 <rellla> *more elegant

21:17 <enunes> anarsoul: in https://gitlab.freedesktop.org/mesa/mesa/merge_requests/914 I'm introducing another optimization loop after lowering ints to floats, I wonder if the new pass for sincos shouldn't just go at the end of lima_program_optimize_fs_nir ?

21:30 <anarsoul> enunes: I think it should go after your second optimization loop

21:33 <enunes> anarsoul: seems good to me too, if you ack 914 we could try to merge it now and then you rebase on top? :)

21:34 <anarsoul> sure

22:18 <enunes> hmm I think I stumbled on another bug with this vectorizing change

22:19 <anarsoul> ?

22:19 <anarsoul> I thought there were not piglit regressions?

22:20 <enunes> looks like vec4 fcsel from nir assumes that each component of the condition will be used to select the same component from the two options

22:20 <enunes> but lima can't implement that since we only have 1 component condition

22:20 <enunes> so we proably need to add fcsel to be turned into scalars

22:21 <enunes> and this fixes a few tests that were failing because of that even before I tried vectorize

22:22 <enunes> yeah there weren't regressions running vectorize 1 time, I turned it into a progress loop and it caused... 1 regression, which I was investigating

22:22 <anarsoul> I see