00:54 <anarsoul> glmark2-es2-drm: ../src/gallium/drivers/lima/ir/gp/scheduler.c:395: gpir_sched_node: Assertion `result' failed.

00:54 <anarsoul> *sigh*

00:56 <anarsoul> I guess I need yuq's or cwabbott's help here. I don't understand how gp scheduler works.

01:53 <alyssa> Mmblep

03:46 <urjaman> MIDGARD_MESA_DEBUG actually

03:47 <alyssa> Thanks

04:43 <anarsoul> I had higher expectations of lima gp compiler :(

04:45 <anarsoul> it can't handle nested bcsel nor 9th degree polynomial

04:46 <alyssa> Ook ook.

04:47 <anarsoul> anyway, 9th degree isn't enough. It needs 13th degree to get rid of bcsel

06:58 <cwabbott> anarsoul: uhhh, yeah, the gp scheduler is a complicated beast

06:59 <cwabbott> it *should* work, so you probably hit some pathological case

06:59 <cwabbott> I probably couldn't figure it out myself without putting it in gdb

07:21 <cwabbott> so, the assert that you hit means that we couldn't schedule a node that needed to be scheduled, so we created a move instead, and scheduling that failed too

07:25 <cwabbott> I *think* I remember an issue with the scheduler that could cause it, but to understand it you'd have to understand the whole design of the scheduler first

07:25 <cwabbott> it has to do with those pesky double-wide ops that take 3-4 inputs, like bcsel

14:35 <alyssa> Wacky

16:33 <anarsoul> cwabbott: probably a silly question, but is there a design doc for gp compiler?

16:36 <cwabbott> anarsoul: unfortunately not, although there were some emails between me and yuq where I explained stuff

16:36 <anarsoul> if there's nothing private, could you forward them to me?

16:37 <cwabbott> I'm trying to finish a rework of the scheduler I almost finished a while ago, including writing up a more informative comment

16:37 <cwabbott> sure

16:46 <cwabbott> anarsoul: what's your email?

16:46 <anarsoul> cwabbott: anarsoul at gmail

18:09 <anarsoul> cwabbott: mixed top/bottom posting is evil. It's extremely hard to follow this email

22:14 <kszaq> Good day everyone. I am trying to run Panfrost in mixed arch environment, that is aarch64 kernel with arm userspace, on T820. I fixed passing array pointer in https://gitlab.freedesktop.org/kszaq/mesa/commit/e0a07be but still getting only DATA_INVALID_FAULT. I stumbled upon https://gitlab.freedesktop.org/mesa/mesa/commit/97aa054 that suggest an assumption if userspace is 32-bit -> use 32-bit GPU descriptors but even with the assumptio

22:14 <kszaq> the same only-errors situation happens. I would be greatful if someone can tell me whether this assumption is correct or should I look somewhere else?

22:19 <HdkR> I don't think anyone is testing a mixed bitness environment atm

22:56 <kszaq_> I would assume so as there are few use cases.

22:59 <kszaq_> I am very new to panfrost, mesa and gpus in general so I will be asking questions about easy things: is there a way to dump the data passed to GPU that was reported as invalid in my case?

23:04 <HdkR> I don't think panwrap supports wrapping the panfrost drm. probably need to trace back which buffer is actually causing the GPU fault

23:18 <alyssa> PANTRACE_BASE=/dev/shm

23:18 <alyssa> ^^ set that

23:18 <alyssa> And then `pandecode /dev/shm`

23:30 <HdkR> There we go, alyssa has the hookup