02:22 <daniels> alyssa: weston will support partial_update very soon i hope, but not yet https://gitlab.freedesktop.org/wayland/weston/issues/134

02:25 <daniels> also, i915g (the gallium one, not classic) basically exists because someone made the mistake of shipping i915 chromebooks, the i915 gpu can only do FS in hardware (no VS), and the chromeos team decided that it was better to at least use llvmpipe for VS

02:38 <HdkR> urjaman: Fragment shader, vertex shader

02:39 <urjaman> ah, much clearer on those, thank you :)

02:39 <HdkR> daniels: That's good information, I didn't realize i915 couldn't do VS :D

06:25 <alyssa> daniels: Woop!

07:23 <anarsoul> daniels: has EGL_KHR_partial_update landed in mesa?

08:31 <Ashy> gregkh's staging repo has some commits from ayufan so i guess that answers that question :)

13:57 <tomeu> narmstrong: have pushed some patches to my winsys branch that disables buffe_age, so weston redraws the whole screen every frame

13:57 <tomeu> taken from the lima repo

13:58 <tomeu> when alyssa finishes partial_update support and weston also gains it, it will be used instead

13:58 <tomeu> narmstrong: in the meantime, we can move with winsys work and test on weston just fine

13:58 <tomeu> wl_shm clients work, but I haven't started work yet on egl clients

13:58 <tomeu> and I don't think I will have time until I'm back from holidays, around the 4th

13:59 <tomeu> if you wanted to look at it, I would just compare our resource_create callback with the ones in fd, vc4, etnaviv, etc

13:59 <tomeu> and keep moving closer to what they do

13:59 <narmstrong> tomeu: thanks, I'll have a test

14:00 <narmstrong> yep, I need to look closely how they allocate resource and mimic it

14:00 <tomeu> we may need to return a fake GEM handle to gallium

14:00 <tomeu> the important thing is to return a real dmabuf FD

14:18 <tomeu> narmstrong: iiuic, we need to use this to export a mali buffer: https://gitlab.freedesktop.org/tomeu/mali_kbase/blob/rk3399/driver/product/kernel/Documentation/dma-buf-test-exporter.txt

14:19 <tomeu> is anybody here who could confirm this? maybe daniels?

14:50 <daniels> tomeu: the allocation should be done by either mali or the kms driver

15:10 <tomeu> daniels: oh, you mean that for resources that are PIPE_BIND_SHARED, we should allocate them in the display winsys as we do with PIPE_BIND_SCANOUT ?

15:42 <alyssa> tomeu: Before you poof for holiday, I'm going to have some time to play with your branch. What kernel are you using?

15:43 <tomeu> alyssa: plain 4.20-rc4 plus the DT for this board

15:43 <alyssa> Alright, cool

15:44 <alyssa> Kevin?

15:44 <tomeu> alyssa: nanopc-t4

15:45 <tomeu> it's also rk3399

15:45 <tomeu> oh, I'm carrying this patch as well: https://patchwork.kernel.org/patch/10706103/

15:45 <tomeu> and I'm using this branch for kbase: https://gitlab.freedesktop.org/tomeu/mali_kbase/tree/rk3399

15:47 <alyssa> Alright, thank you! :)

15:52 <alyssa> (Er, ambiguous sentence. What I meant, while you're on holiday, I'll have time to play with it, but then you won't be around to answer questions about what kernel you're using :P)

16:28 <tomeu> yeah, I won't have irc, but if I can help in any way, email me at the address I wrote in PM

21:28 <alyssa> tomeu: Alright, thank you :)