08:55 <amazingfate> Hello, I'm trying to run kodi gbm on my rk3568 board running mainline kernel 5.18. I see this blog:https://blog.tomeuvizoso.net/2019/01/a-panfrost-milestone.html, which says kodi gbm can run with panfrost, but I when I run command kodi-standalone --windowing=gbm, I get a blackscreen, here is the kodi debug log: https://paste.kodi.tv/efuhurocep.kodi. It seems that kodi gbm is not running with panfrost, any ideas?

08:56 <amazingfate> Hello, I'm trying to run kodi gbm on my rk3568 board running mainline kernel 5.18. I see this blog:https://blog.tomeuvizoso.net/2019/01/a-panfrost-milestone.html, which says kodi gbm can run with panfrost, but I when I run command kodi-standalone --windowing=gbm, I get a blackscreen, here is the kodi debug log: https://paste.kodi.tv/efuhurocep.kodi. It seems that kodi gbm is not running with panfrost, any ideas?

11:15 <daniels> amazingfate: you need a newer kernel for rk3568

12:40 <amazingfate> daniels: I've already tried 5.18. Should I try linux-next?

12:41 <amazingfate> I can run x11 and wayland with panfrost now, and glmark2-es2-drm also runs well

12:50 <daniels> that's really odd then, if those all work fine with acceleration then it must be a kodi issue rather than a panfrost issue

19:57 <alyssa> LD_VAR_BUF_IMM.f16.slot0.v4.src_f32.center.store.wait0126 @r0:r1, r61, index:0x0

19:57 <alyssa> arm sure likes modifiers

20:39 <alyssa> I am *so* glad I wrote that perf counter stats script

20:39 <alyssa> was, uh, benchmarking supertuxkart

20:39 <alyssa> $ ./panquick --json | python3 stats.py

20:39 <alyssa> revealed something interesting:

20:40 <alyssa> Blend shaders: 13542972

20:40 <alyssa> I-cache misses: 1910888

20:40 <alyssa> We were calling tons of blend shaders -- this is expected on Bifrost-era hardware due to FP16 blending

20:41 <alyssa> but those calls led to piles of i-cache misses due to the lack of locality

20:41 <alyssa> eliminating the blend shader calls eliminates the i-cache misses entirely

20:57 <HdkR> No way for the hardware to prefetch them?

22:18 <jekstrand> \o/ for data

22:20 <alyssa> jekstrand: :-D

22:27 <icecream95> alyssa: What do you need JSON for?

22:27 <icecream95> Importing a 300 MB CSV file with per-job counters into SQLite works fine for me

22:27 <alyssa> Hmmmm :p

22:28 <icecream95> Next is getting pandecode to output SQL

22:28 <icecream95> (No I'm serious)

22:28 <alyssa> Why SQL and not CSV...?

22:28 <icecream95> * output CSV that can be imported into a SQL database

22:28 <alyssa> Ah

22:29 <alyssa> Yes, I'm a lot happier merging CSV dumps than SQL for obvious reasons :)

22:29 <icecream95> Hmm?

22:30 <icecream95> Oh you mean merging as in `git rebase`?

22:30 <icecream95> I thought you meant cat <(sqlite3 a.db .dump) <(sqlite3 b.db .dump)

22:30 <alyssa> Merging as in assigning to Magre

22:30 <alyssa> Marge

22:31 <icecream95> Magre the Ogre

22:32 <icecream95> Is the obvious reason that you've never bothered to learn SQL?

22:32 <alyssa> actually no [1]

22:32 <alyssa> [1] https://gitlab.freedesktop.org/alyssa/liben/-/blob/main/manager.c

22:33 <alyssa> just that it's a very large hammer to employ :)

22:43 <icecream95> SELECT bo FROM Uses WHERE batch=$batch.seqnum;

22:43 <alyssa> this seems like something I'm supposed to nak but I like SQLite too much :-p

22:44 <icecream95> alyssa: I can't pull your branch bifrost/nodearray because I still have your branch 'bifrost'...

22:44 <alyssa> I deleted that remotely, uhh

22:45 <alyssa> git remote prune alyssa

22:48 <icecream95> Oh so you doubled memory bandwidth for nodearray? Lemme do some performance testing so I can NAK it better

22:53 <alyssa> if the goal is optimal perf of the RA algorithm ... decoupled register allocation is hard to beat.

22:54 <icecream95> alyssa: I thought the goal was optimal perf of the RA *implementation*?

22:54 <alyssa> that's what I meant just now, sorry, I realize that was ambiguous

22:56 <icecream95> alyssa: But what do you mean by "decoupled"?

22:56 <alyssa> Decoupled register allocations "decouple" spilling from register assignment.

22:57 <alyssa> Rather than

22:57 <alyssa> failure of the register assignment driving spilling in a loop,

22:57 <icecream95> Spilling isn't that expensive if you don't invalidate liveness

22:57 <alyssa> spilling is handled upfront based purely on the register demand of the program

22:58 <alyssa> (this also produces fewer spills/fills in a few cases)

22:58 <alyssa> but that's significantly more complicated.

22:59 <icecream95> After SIMDifying, the actual time spent in RA is pretty insignificant compared to calculating constraints for LCRA

23:00 <icecream95> (or interference, whatever term for it you are using now)

23:00 <alyssa> Okay

23:01 <icecream95> (Why? RA has much nicer memory access patterns, for one)

23:08 <icecream95> alyssa: Hmm... your nodearray change made compiling shaders/skia/781.shader_test take 0.3 seconds longer

23:08 <icecream95> But it still takes 27 seconds to compile, because you didn't include the liveness patches

23:11 <icecream95> For smaller shaders, it is half a percent slower

23:13 <alyssa> I'm happy to eat a half a percent of compile-time to not have to think about RA right now

23:15 <icecream95> alyssa: What's wrong with the vec8 patch I already wrote?

23:23 <icecream95> alyssa: If you are going to have a 64-bit sparse value, why not just give 32 bits to each component rather than making the value 16 bits?

23:23 <icecream95> Also, cleaning up all the magic values rather than s/uint32_t/uint64_t/ would probably have been better

23:26 <icecream95> alyssa: Oh and you broke the binary search as well

23:27 <icecream95> No wait you didn't, because you also forgot to remove `assert(key < (1 << 24))`

23:38 <icecream95> alyssa: Even if you don't merge SIMD, the lcra_solution_mask stuff makes a big impact, so you should take what you can from the patch