05:59 <daniels> icecream95: sort of yes to both. just just starting on the kernel

07:25 <HdkR> https://www.cnx-software.com/2022/06/16/mediatek-genio-1200-linux-system-on-module-powers-cortex-a78-a55-aiot-development-kit/ Looks like a fantastic board for running Panfrost on :)

07:32 <rasterman> HdkR: ooh .. that has some pretty good cpu cores (for a "dev board"). the gpu is decent too. though i have a g76 to run panfrost on for now so i'm happy, but that above looks pretty nice. it'd make for a pretty good media-player pc for your tv or a casual "daily browse the internet" pc ...

07:33 <rasterman> no pricing though that i can find...

07:37 <icecream95> HdkR: Seems to be slower than the MT8195 in the newest Valhall chromebooks... I think that can do 3 GHz on the big cores

07:38 <daniels> HdkR: gen9? boring :P

07:43 <HdkR> Looks like the device is planned to be $439.00

07:43 <HdkR> daniels: Need to complain to Mediatek about that one :P

07:45 <rasterman> daniels: csf gpu's are easier to find... :)

07:45 <rasterman> its the rarity of a valhall in dev board form that is interesting :)

07:48 <HdkR> Might need to get one of those just for playing with panvk + fex-emu

07:55 <rasterman> :)

08:04 <daniels> rasterman: getting easier to find now they're ramping up into production ...

08:04 <rasterman> thankfully :)

08:04 <daniels> HdkR: $439 is pretty punchy tbh

08:04 <rasterman> just has been a struggle for a while.

08:04 <daniels> though you usually pay a premium for SoM + carrier board over SBC

08:04 <rasterman> and pay a premium for low volumes

08:06 <HdkR> daniels: Definitely for some random users. Not too bad compared to something like Jetson Orin :P

08:09 <daniels> yeah, but it's ~4x the cost of your average performance SBC

08:09 <daniels> *average, performance-competitive, SBC

08:15 <HdkR> Sadly

08:19 <rasterman> yeah. that's pretty pricey.

09:58 <icecream95> I should probably get back to adding support for CSF to Mesa... the command stream should be pretty simple to emit if I ignore dirty tracking for now

18:38 <alyssa> 1 file changed, 49 insertions(+), 129 deletions(-)

18:38 <alyssa> i heard you like deleting things

19:52 <jenneron> if anyone needs working gpu on peach-pit and peach-pi chromebooks, i merged kernel-side patches to postmarketOS, though it's still required to build patched mesa with t620 enabled

20:08 <alyssa> jenneron: What's the status of t620 with panfrost on mainline?

20:08 <alyssa> [If things work I don't mind enabling it upstream, keeping in mind I don't have and don't want the hardware ;) ]

20:09 <macc24> but i want the hardware ;D

20:09 <jenneron> as i've reported before, t620 itself works, but performance on exynos is very poor, this patch is supposed to workaround it https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/testing/linux-postmarketos-exynos5/0037-soc-samsung-pm_domains-Bring-back-old-driver-impleme.patch

20:10 <jenneron> i don't have this device anymore, but i've been reported that it scores ~750 in glmark2 and has some issues with xorg

20:13 <jenneron> these are letters from the one who tested it https://dpaste.com/DJSJDLRHL and https://dpaste.com/4S4MT6XWW

20:25 <HdkR> Fun, platform driver issues

20:31 <alyssa> jenneron: Hum, ok

20:32 <alyssa> I guess big shrug on whether to enable upstream

21:57 <icecream95> I wonder if CSF command streams are turing-complete. Even if not, I think useful computation could still be done with them

21:58 <icecream95> Once I get my hands on an RK3588 board, maybe I'll see if I can write a "GPU-accelerated" snake game that uses a command stream for all logic and rendering

22:08 <anarsoul> icecream95: are you getting quartzpro64?

22:11 <alyssa> icecream95: the CSF command stream is firmware-defined, right?

22:11 <alyssa> and that firmware isn't signature checked, is it?

22:12 <alyssa> ;-p

22:14 <icecream95> alyssa: Not exactly? I think the top-level command stream could be interpreted by firmware, but the second level which has the actual draw commands is done in hardware, maybe?

22:15 <alyssa> ah, yeah, that sounds likely

22:16 <alyssa> maybe?

22:16 <alyssa> it's my understanding things like indirect draws are done on the MCU, so maybe draws are too

22:17 <icecream95> Do we have any idea what the microcontroller clock speed is? Because it would need to be pretty high to interpret the draws, which would maybe take 200 cycles each

22:23 <icecream95> (The blob uses at least 17 commands per draw, and each of them would be on the order of ten MCU instructions. Also copying from the constructed draw to less volatile memory would take some time to do with firmware)

22:26 <alyssa> Yeah, that's fair. I guess we'll find out in due time.

22:43 <icecream95> alyssa: I'm wondering whether to keep using pan_pack for descriptors that use a command stream. It'd make implementation somewhat easier, but dirty tracking is hard to do except by splitting the structs up in to many smaller ones

22:48 <icecream95> Maybe the way to do it is by passing ctx->dirty (or a value derived from it) into the pan_pack macro?

22:49 <icecream95> But then the XML would have to depend on implementation details of drivers...

22:59 <jenneron> alyssa: xorg issue should probably not block enabling t620 in upstream. i had to blacklist panfrost kernel module anyway, iirc xorg segfaults when it's probed

22:59 <jenneron> i should get hardware and test everything again

23:18 <alyssa> icecream95: Without seeing the details of the CSF command stream, it's hard for me to say.

23:19 <alyssa> Panfrost's flavour of GenXML is optimized for packing Mali descriptors, IIRC I specifically removed command stream functionality from the intel/v3d upstream when I forked it off.

23:19 <alyssa> Maybe you just want to restore that functionality (from v3d's genxml)?

23:20 <alyssa> Passing dirty state into GenXML seems like a huge hack that should not be necessary.

23:22 <alyssa> Have you published any documentation on the CSF command stream format?

23:24 <icecream95> alyssa: I don't remember, but the commands are simple enough:

23:24 <icecream95> One byte flags, one byte address, six bytes payload

23:24 <alyssa> (It would be useful to have that info in Mesa, I'd be happy to have notes live in panfrost's webspace on mesa3d.org)

23:24 <icecream95> Most commands write either four or six bytes into a 256-word buffer

23:25 <icecream95> Actual draws are flagged with bits in the flag byte

23:25 <icecream95> The buffer holds a shuffled version of the v9 descriptors

23:27 <alyssa> Interesting.

23:28 <icecream95> (I assume that the buffer actually exists as a linear block of RAM, but I could be wrong)