06:57 <tomeu> alyssa: foo.patch looks great to me, thanks!

07:20 <macc24> lol apparently there is some info on rg552 handheld and it's going to have rk3399 chip. in 2021.

07:28 <CounterPillow> I don't think there's a 3599 yet, so rk3399 doesn't seem like a terrible choice in current year.

07:28 <macc24> 3588*

07:29 <macc24> rk3399 is... kinda old

07:30 <HdkR> Sounds like an okay one for support though

07:30 <CounterPillow> so am I but I still try to do new things ;_;

07:30 <urja> macc24: lol i still havent even gotten a 3399 device :P

07:31 <macc24> there you go

07:31 <macc24> now it's your problem

07:31 <CounterPillow> I've got one arriving tomorrow.

07:31 <macc24> CounterPillow: kevin?

07:31 <CounterPillow> No, ROCKPro64

07:32 <macc24> ah, cpp;

07:32 <macc24> cool*

07:32 <macc24> i'd gladly exchange my kevin for a bob

07:33 <macc24> the 2400x1600 screen kills performance of everything :<

07:34 <urja> program the VOP scaler to run it from a 1200x800 framebuffer

07:34 <macc24> hold my beer

07:35 <urja> (= i think you could just xrandr that up... the syntax might not be fun... not sure how it works with non-X tho :P)

07:38 <macc24> o/ alpernebbi

07:38 <alpernebbi> yo

08:00 <macc24> alpernebbi: do you know of any way to get ap uart console on kevin?

08:01 <alpernebbi> dunno

08:02 <alpernebbi> closest thing I know of is the servo debug board

08:03 <macc24> i wish i had servo

08:03 <alpernebbi> me too

08:13 <macc24> my vacuum cleaner broke yesterday so i put a G31 inside of it and it started to suck again

08:19 <HdkR> I don't think that is fair. It's a GPU that is woefully underpowered for the product it was dropped in to

08:27 <HdkR> Or maybe perfectly powered depending on if you're trying to push it too far :)

08:27 <HdkR> Widescreen 480p? Perfect

08:28 <macc24> Did you mean: "Widescreen 240p?"?

08:30 <HdkR> 854x480

08:34 <macc24> trust me, either g31 is too slow or panfrost is too slow

08:34 <macc24> 854x480 is a bit too much

08:35 <macc24> i can't play minecraft bedrock edition in 60fps on odroid go super :(

08:38 <HdkR> "you're trying to push it too far"

08:55 <icecream95> Interesting... I thought Z/S AFBC was the same as non-YTR RGBA, but some tiles are invalid for a decoder set to RGBA, so I guess there are some additional compression modes for depth

08:56 <icecream95> (the 24-bit depth value is spread across the RGB channels, stencil is alpha)

09:12 <icecream95> Or maybe it isn't so much like RGBA after all, and I just messed up with my AFBC test program...

10:25 <robmur01> macc24: the purpose of G31 is to render the Android UI (at probably not more than 1080p60). Seriously. Adjust expectations accordingly...

10:25 <macc24> robmur01: do you know how to use qos stuff? i don't see anything in rockchip's kernel about it

10:26 <robmur01> you jest, but in fact a "smart" vacuum cleaner with, say, a 4" a touch display is exactly the kind of market opportunity for putting a tiny GPU in an area (== cost) and power-constrained embedded SoC ;)

10:27 <HdkR> Roomba with 4" rendered display roaming around your house

10:27 <macc24> robmur01: rk3326?

10:28 <robmur01> QoS? Nope, sorry. Even if Rockchip used our interconnects, which they don't, it would be very SoC-specific.

10:28 <macc24> :|

10:29 <HdkR> They don't use CCI?

10:31 <HdkR> Here I thought it was just Nvidia being weird and not using it

10:31 <macc24> mediatek uses their own too afaik

10:36 <macc24> at least on mt8183

10:36 <Rathann> hi

10:36 <Rathann> so many people here :)

10:39 <Rathann> is https://gitlab.freedesktop.org/panfrost/mesa/-/issues/ the right place to report bugs?

10:39 <macc24> yes

10:39 <macc24> wait no

10:39 <macc24> there -> https://gitlab.freedesktop.org/mesa/mesa/-/issues/

10:40 <Rathann> ah, so upstream mesa issue tracker

10:40 <Rathann> ok

10:41 <Rathann> I'm getting a lot of unhandled page faults after upgrading mesa 21.0.2 to 21.1.1

10:41 <macc24> on what gpu?

10:41 <Rathann> T860 in a Pinebook Pro

10:41 <macc24> can you try on main branch of mesa?

10:43 <Rathann> I guess I can

10:43 <Rathann> here's my downstream (Fedora) bug report for what it's worth: https://bugzilla.redhat.com/show_bug.cgi?id=1965784

10:44 <Rathann> I'll try with mesa main branch and file an issue if it occurs there as well

10:45 <macc24> if it doesn't fix it let me know and i will try to reproduce on my rk3399 machine

10:45 <Rathann> sure!

10:46 <Rathann> and thanks

10:57 <robmur01> HdkR: RK3399 (and presumably Rk3368?) use CCI-500 to connect the two CPU clusters, but everything else is on some other NoC

10:58 <HdkR> huh

11:08 <HdkR> Waiting for that 8 core Cortex-X2 device to replace my laptop :D

11:09 <HdkR> and 64 core to replace my desktop :)

11:09 <HdkR> Max config DSU-110 + CI-700 please

11:25 <robmur01> nah, forget CI and DSU, you want CMN with direct-connect clusters. Big boy stuff :)

11:27 <HdkR> Hm, you right

11:29 <HdkR> Make sure to have those X2 cores run at 4Ghz as well while we are at it :P

12:05 <Rathann> macc24: looks like it's fixed in main, I can't reproduce it anymore

12:05 <Rathann> thanks!

12:30 <macc24> Rathann: sure no problem

13:04 <Rathann> macc24: it's probably a89bc59980b3ea7b2f03d2994bae7dda689f637f

13:50 <Rathann> but not only, it depends on previous MRs

20:49 <icecream95> Rathann: It was probably fe9d37b0c6e8 that fixed it, which should be in the next stable release

20:54 <Rathann> icecream95: thanks, https://gitlab.freedesktop.org/mesa/mesa/-/issues/4737 looks exactly like my issue

20:54 <Rathann> I'll try building 21.1.1 with the patch you mentioned as it seems to apply cleanly

21:20 <Rathann> confirmed, patch fixes the issue

21:21 <Rathann> icecream95: thanks a lot!

22:42 <cyrozap> Has anyone done any performance microbenchmarks of Midgard/Bifrost instructions on various cores? e.g., cycles per instruction? Or is that officially documented anywhere? I ask because I recently did that for an unknown 8051 core and it was super helpful in performance-tuning some assembly. There were a lot of instructions that I thought were "simple" but ended up taking way more cycles than I thought

22:42 <cyrozap> they would. So, I figured it would be helpful to do that for these GPU cores as well, since that might help squeeze some more performance out of my Chromebook's T760 MP4.

22:45 <HdkR> I don't believe anyone has done this on Mali. There has been work on this with Nvidia GPUs though

22:45 <cyrozap> Oh, and the other benefit is that once you know the number of cycles and bytes each instruction takes, as well as the exact operations those instructions perform, you can plug them into an SMT solver to get an optimal instruction sequence for higher-level operations.

22:48 <cyrozap> HdkR: Thanks! In that case, maybe I'll give it a try sometime.

22:49 <HdkR> Don't forget that throughput is also important

22:49 <cyrozap> Ah, right, because it's all pipelined.