11:55 <robmur01> BTW, something in the recent changes has made the retroarch UI start rendering correctly again, hooray!

11:57 <alyssa> \o/

11:57 <robmur01> still getting the "unhandled 67" spam with kmscube in rgba mode, but maybe that's another GBM peculiarity

12:50 <urjaman> ugh ... now trying to open the applications menu in xfce makes Xorg hit the assert at midgard_schedule.c:1245

13:11 <HdkR> Fun, straight up spill failure :)

13:15 <daniels> glamor :(

14:33 <shadeslayer> bbrezillon: alyssa https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2426

14:33 <tomeu> narmstrong: we have everything in 5.4 already for t720 and t820, right?

14:34 <tomeu> I guess that coherent pagetable walks isn't needed there

14:34 <robmur01> tomeu: yup, the kernel fixes are now in rc4

14:34 <tomeu> awesome!

14:35 <robmur01> and the coherency thing was premature anyway - I'll revisit that at some point to figure out proper 'dma-coherent' support

14:35 <robmur01> (essentially we need a way to not force write-combine mappings)

14:37 <tomeu> robmur01: nice, thanks for taking care of it

14:39 <robmur01> coherent H/W is pretty rare anyway ;)

14:41 <tomeu> narmstrong: review welcome here :) https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2427

14:42 <HdkR> Coherent hardware is good stuff, if you can actually get any :P

14:43 <HdkR> Everyone always hopes that UMA = coherent, but that is usually never the case :(

14:44 <robmur01> Hmm, I'd struggle to call the Arm Juno testchip "good stuff" with a straight face :P

14:45 <HdkR> haha

14:45 <HdkR> Juno is too old at this point :)

14:45 <robmur01> GPU-wise it was too old 5 years ago

14:47 <HdkR> Was Juno coherent to the caches though?

14:47 <narmstrong> tomeu: not sure the drm_sched fix is in 5.4

14:50 <robmur01> yup, the GPU is I/O-coherent (i.e. it can snoop, but doesn't play the full coherency protocol), so it's useful for trying stuff out

14:51 <tomeu> narmstrong: I think it is, or at least I stopped seeing it at all after updating

14:51 <HdkR> Neat

15:00 <narmstrong> tomeu: indeed, it's here https://github.com/torvalds/linux/commit/5b3ec8134f5f9fa1ed0a538441a495521078bbee#diff-d02f2f3091d5d209adcac3cc282b0ccb

15:04 <tomeu> things are coming together :)

19:52 <Lyude> alyssa or anyone else who knows: would it be possible in theory to implement opencl (not taking into consideration non-panfrost specific mesa work that would be needed for that) on midgard?

19:53 <HdkR> yes

19:53 <HdkR> Midgard shipped a CL desktop profile driver originally

19:53 <Lyude> HdkR: I figured :)

19:55 <Lyude> that gives me some stuff to think about

19:56 <HdkR> oh no, stuff

19:56 <HdkR> :)

20:56 <alyssa> Lyude: That's what I've been working on since XDC! :)

20:56 <alyssa> ...slowly. It's a lot of work and I'm part-time :(

20:59 <HdkR> The more company the better :D

21:25 <Lyude> alyssa: yessssss

23:08 <urjaman> oh yeah i'm curious, anything interesting you planning to use OpenCL for? Or just doing it because cool to make it compute anything? :P

23:09 <HdkR> build it and they will come? Seems like a common question at XDC is "When will it support OpenCL?"

23:13 <urjaman> Yeah I was just thinking if you have something in mind -- like the only idea i have is maybe arbitrary codec decoding/encoding but i havent looked at whether there are actual implementations (I'd expect the eg. VPU on the rockchips being better for the usual H.264 but...)