05:45 <Werner> Dear Panfrost people, yesterday I try to get Panfrost drivers, compiled natively from scratch, to work on my OPi1+ (Allwinner H6, Mali T720, Linux 5.6.2, Armbian (Ubuntu)Focal) but failed. It freezes the whole board after a couple of seconds. Everything I could capture I have sent into a comment to NicoD's already existing issue report from about a month ago. Maybe you have a chance to take a look at it. https://gitlab.freedesktop.org/panfrost/linux/-/

05:45 <Werner> issues/2

05:54 <mixfix41> i thikn they said arch linux has panfrost included on their you could try that from one person said in here. besides could be a lot of factors but it should work

05:55 <mixfix41> i use slackware personally its hit or miss but i havnt yet gone to arch to check it out either

05:56 <mixfix41> or since you have a t720 you might try prawnos

05:57 <Werner> I am not sure if this would make a difference since both OS would share mostly the same base like DTB which could be an issue already. Who knows...

05:59 <mixfix41> on application basis and with arm you have to

05:59 <mixfix41> for me anyways personal experiences

06:02 <mixfix41> actually im pretty crippled at building the kernel it just seems so monumental i understand

06:07 <mixfix41> it doesnt add up thoughs wouldnt x just fall back on non acceleration or refuse to start why would it lock at all

06:09 <Werner> No clue

06:12 <mixfix41> we'll get there ^

06:28 <tomeu> Werner: mixfix41: maybe it can help to see how we run tests in h64 boards: https://lava.collabora.co.uk/scheduler/job/2286143

06:28 <tomeu> you can download the kernel, dtb, and mesa build from there to check what component is causing problems

06:29 <tomeu> but I would indeed double check that the GPU is getting enough power at all the frequencies

06:29 <tomeu> it could help to lock it up at a lower frequency for testing, using the sysfs interface to devfreq

06:36 <Werner> I will try to dig a bit deeper into. Thanks

06:43 <Werner> tomeu, You may have been right. I pushed the gpu governeur to powersave and it did not crash yet. I got glxinfo and glx gears running

06:43 <tomeu> promising!

06:43 <Werner> Man that is an awesome morning

06:44 <Werner> I will try to clock it higher step by step and run glxgears for several minuts to see how it performs

06:47 <Werner> Is the dmesg output "Purging xy bytes" and "panfrost_gem_shrinker_scan" about every five seconds intended?

06:51 <urjaman> "intended"? *shrug* ... but normal? yes.

06:52 <urjaman> there exists a patch to silence it but i dunno what's the state on that going anywhere :P (mostly feels like because nobody is in a hurry with such tiny stuff...)

06:53 <Werner> Aight, no big deal. Was just wondering why it spams the dmesg :)

07:07 <Werner> At 360 it ran into trouble

07:09 <Werner> http://paste.debian.net/1139014

08:21 <Werner> With some cooling I pushed it to 384, though it throw the (I guess) same error when killing glxgears

09:19 <robmur01_> urjaman: yeah, I was just thinking about reviving that patch with more strongly-worded justification, now that I have GDM working on my board and see the full force of the spam too...

09:30 <icecream95> robmur01_: I built a new kernel without ARM_ERRATA_818325_852422, but the other cores are still slower than core 0 for conditional instructions

09:47 <robmur01_> icecream95: hmm, the 852422 workaround is supposed to have "negligible performance impact" anyway, but it's still mighty weird whatever

09:47 <robmur01_> I need to get my 3288 going again to see if it's easily reproducible, or whether there's perhaps some system-specific bootloader behaviour involved too

09:48 <Werner> Aight, it seems like Panfrost just running fine with good cooling. It does not like thermal throttling though.

09:49 <robmur01_> BTW, is your "fn" an actual implementation of something useful, or just a synthetic test case? Because AFAICS most of those conditional instructions could be avoided anyway ;)

09:53 <icecream95> That's a synthetic test, but I derived it from some real-life code that iterated over a vector<bool> (which has now been removed from C++...)

11:56 <tomeu> alyssa: pushed some more stuff, now I got to bifrost_tiler_meta stuff finally

13:43 <alyssa> tomeu: \o/

14:03 <tomeu> alyssa: I'm a bit out of clues on why it's not liking my tiler heap: https://paste.centos.org/view/f69e4801

14:04 <alyssa> tomeu: polygon_list_size = 0x65400, <-- for starters this field was wrong

14:05 <tomeu> interesting, that field seems to be supposed to hold a pointer to the bifrost_tiler_meta descriptor

14:06 <alyssa> Assume everything related to bifrost tiler is wrong right now :2

14:08 <tomeu> I didn't get to the fragment descriptor yet, was still at the tiler one

14:08 <alyssa> got it

14:18 <alyssa> robher: https://people.collabora.com/~alyssa/whistles.txt

14:19 <alyssa> wasnt me

14:19 <alyssa> <-- was her

14:29 <alyssa> Meanwhile compiler bugs

14:43 <tomeu> alyssa: pushed something that populates the tiler descriptor a bit nicer

14:46 <tomeu> alyssa: new trace: https://paste.centos.org/view/9e266a1d

14:46 <tomeu> don't know why it keeps complaining about the tiler descriptor

14:47 <tomeu> *tiler_meta

14:50 <alyssa> tomeu: Hm, did we see if there are spooky hidden fields?

14:50 <tomeu> alyssa: not yet, will have to wait to tomorrow

14:50 <tomeu> I'm about to finish for today

14:50 <alyssa> alright, thank you!

14:51 <tomeu> I think there could easily be in mali_framebuffer after the address to the tiler_meta descriptor

14:51 <alyssa> Hmm, right

14:52 <alyssa> Also keep in mind fault_pointer isn't always precise

14:52 <alyssa> could be the tiler_heap_meta instead, etc.

14:53 <tomeu> yeah

14:53 <alyssa> tomeu: should I continue this or compiler?

14:54 <tomeu> alyssa: maybe compiler?

14:54 <alyssa> aight!

14:54 <tomeu> guess it could be a better use of your time, but who knows, maybe I won't be able to crack this nut :)

14:54 <alyssa> (BTW - vertex job in kmscube runs on your branch)

14:55 <alyssa> (Not entirely *correctly* but it does execute. So you're getting close)

14:56 <alyssa> .tiler_heap_free = memory_13 + 0,

14:56 <alyssa> is suspect

14:57 <alyssa> although it doesn't change in subsequent frames, they just alternate the entire buffer

16:27 <Lyude> btw alyssa - if I get the time I will try again this friday to get some panfrost time

16:29 <alyssa> ok!

16:51 <robher> alyssa: Seems like we are tearing down drm_mm before all the BOs are unmapped.

17:34 <alyssa> robher: could be

18:55 <alyssa> tomeu: Might want to pick the top commits from alyssa/v12b which makes vertex shaders behave a lot better

23:21 <alyssa> Obscure bugs are obscure..

23:21 <HdkR> Unit tests capturing fun things? :D

23:22 <alyssa> Sadly no, if I had a good unit test to capture this I'd know what the bug was :\

23:26 <HdkR> hehe

23:28 <alyssa> might need to call it a night and sleep on it