08:16 <bshah> hm any idea about how to best generate useful apitrace for lima? :D

08:17 <bshah> should trace generated with trace --api egl would do?

08:17 <bshah> or I should pass any specific options?

08:22 <yuq825> it depends on if your application use glx or egl. for glx, no option is needed, for egl, need -a egl

08:22 <bshah> okay, so since testing wayland-egl client, will use -a egl, thanks

08:43 <rellla> yuq825: what about moving https://gitlab.freedesktop.org/lima/web/wikis/home to a dedicated lima page on http://linux-sunxi.org ?

08:47 <yuq825> I don't think a move is needed, for just usage, sunxi could reference the lima page

09:01 <rellla> yuq825: it's just because the gitlab wiki page is very difficult to find and not editable. i can duplicate it ...

09:02 <yuq825> I can add you guys to be able to edit this page, let me try

09:11 <yuq825> done

09:11 <rellla> thanks, i see.

09:12 <rellla> now it's just about, what we should update :)

10:27 <bshah> So I traced very simple application, normal window with color changing every few seconds : https://bshah.in/qmlscene.trace I at least don't see any warnings from lima side (for example, ppir nir_cf_if missing or $things) which I see in other apps. Can anyone take a quick look at my trace? :)

10:32 <bshah> or should I report bug/gitlab issue probably?

10:43 <enunes> bshah: what mesa version are you using, and what bug do you see?

10:45 <bshah> enunes: mesa 19.1 (I should try git master, but stuck with 19.1 for now due to $issues), bug I see is I see either completely transparent rectangle or white rectangle instead of colored window

10:45 <bshah> the apitrace I have is supposed to loop through few colors every few seconds ^^

10:45 <enunes> bshah: I tried qt applications some time ago and some of the built-in examples worked with master but nothing on 19.1, so I think it is not very useful to try 19.1

10:46 <bshah> enunes: okay, have you tried any of qml examples? or just qt widgets?

10:47 <bshah> for instance, all qtwidgets apps work fine for me, just not qml

10:57 <enunes> don't remember really, but please try it on master

11:19 <MoeIcenowy> bshah: maybe you should try my deaccel branch

11:20 <bshah> MoeIcenowy: got link?

11:20 <MoeIcenowy> https://gitlab.freedesktop.org/icenowy/mesa/tree/lima-icenowy-exp

11:22 <bshah> will try this once I finish trying master branch :)

11:32 <bshah> hm

11:32 <bshah> git master doesn't even build : https://invent.kde.org/snippets/337

11:32 <bshah> potentially my libdrm is out-of-date?

11:38 <bshah> meh, no idea why this fails such randomly, line it is failing on hasn't been touched from forever

11:39 <enunes> it has always built fine for me and CI also builds it, so I guess it's something with your system

11:42 <bshah> hm probably something to do with my system (using musl+alpine ^^)

12:19 <bshah> asking in #dri-devel... mesa git master builds fine on my amd64 + glibc machine... so something is probably wrong with musl or somethng

15:14 <bshah> enunes: 90% of my issues are gone with lima master :O

15:19 <anarsoul> 10% is missing cf? :)

15:19 <bshah> yus :P

15:21 <enunes> that might still take a while

15:22 <bshah> still this is awesome ... omg

15:23 <anarsoul> I have a day off tomorrow so I'll try to move generating succ/pred lists to the very end

15:26 <enunes> anarsoul: nice, do you plan to work on top of the changes I did in the scheduler? I just hope we don't end up with largely conflicting patchsets, that is, if the one I have doesn't conflict with the current cf patchset already...

15:26 <anarsoul> enunes: yes

15:27 <anarsoul> I'll use https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1412 as a base

21:07 <anarsoul> enunes: are you around?

21:07 <anarsoul> does https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1357 depend on https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1412 ?

21:08 <enunes> anarsoul: it's the other way around, 1412 depends on 1357

21:08 <anarsoul> hmm

21:09 <anarsoul> but 1357 uses pipeline regs while scheduler is still not aware of it

21:09 <anarsoul> am I missing something?

21:12 <enunes> anarsoul: it still works because that node is not scheduled by itself but recursively in the special case of insert_to_load_tex

21:12 <enunes> with 1412 that continues to work even removing the insert_to_load_tex special case

21:12 <anarsoul> OK, sounds good

21:12 <anarsoul> let me double check everything...

21:23 <anarsoul> enunes: where +1 is coming from in "num_components = load_tex->src_coords.ssa->num_components + 1" ?

21:25 <enunes> anarsoul: the "varying fetch" that prepares the coordinates + projector has the field "p - perspective", which uses the z or w component of the same register to divide as a projector

21:25 <enunes> the +1 is because I need to take as many coordinates as were in the tex coordinates and add the projector there

21:26 <anarsoul> enunes: then probably add a comment there to explain it?

21:26 <enunes> yeah I can do that

21:27 <enunes> I don't like those moves either but I didn't see other way to merge coordinates and projector in a single register

21:33 <anarsoul> I wonder why it was separated in NIR, if I understand correctly it's a single vec3 or vec4 in glsl

21:36 <anarsoul> looks like vc4 doesn't support texture2DProj

21:39 <anarsoul> oh, it does, but via nir_lower_tex pass