14:06 <icecream95> alyssa: Tarball with some performance data for various RA patches: https://0x0.st/oByD.zst

14:44 <technopoirot> HdkR: thanks for the Mali-G31 MP1 links

15:06 <robmur01> fun fact: G51 and G31 "MP2" are technically still a single core, just a much fatter one than the respective MP1 configs

15:17 <cphealy> robmur01: What about G52-MP2? Is that truly 2 cores?

15:26 <robmur01> cphealy: yes (and whether they're skinny 2EE cores or full-fat 3EE cores is a global choice, no weird mix-and-match like G51 MP3 and up)

15:27 <cphealy> ack

15:27 <CounterPillow> I'm on 2EE because Rockchip needed to fit more random blitters onto the chip :(

17:50 <alyssa> https://pbs.twimg.com/media/FUEAhf1VUAEseMt?format=jpg&name=medium

17:50 <alyssa> i've been called out :-p

17:54 <cphealy> lol

18:30 <CounterPillow> wouldn't be a problem if we cloned you a few times :D

18:35 <CounterPillow> alyssa: btw regarding the DRM_FORMAT_MOD_INVALID stuff, I noticed that weston doesn't break, only plasma does. It seems to try using AFBC on a plane that doesn't support it and then gives up. If this is something that needs fixing in the kernel let me know and I'll put it on my list of rough rockchip edges

18:36 <alyssa> CounterPillow: I don't actually remember whose bug it is

18:36 <alyssa> There was discussion and the consensus IIRC was to treat INVALID as LINEAR in Mesa

18:37 <alyssa> but that might've been to avoid breaking the world rather than actual correctness

18:37 <CounterPillow> I see. Anyway, thought it's interesting that weston doesn't seem to trigger the "is this modifier supported" function in the kernel but kwin_wayland_drm does. Maybe weston just piggybacks whatever mode the console had set, and the console seems to get it right

18:38 <alyssa> Weston is the gold standard for implementing modern DRM interfaces correctly.

18:38 <jernej> ideally, all kernel drivers should report modifiers they support, even if it's only linear

18:38 <alyssa> It's everyone else I'm worried about.

18:38 <CounterPillow> I'm currently compiling kwin (and with that, seemingly half of KDE, yikes) from git source to see if the changes they've made to the DRM backend have improved things at all

18:38 <jernej> I already fixed one of them, to make it work with panfrost

18:39 <alyssa> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12666

18:40 <CounterPillow> it seems like some parts of the new vop2 driver just don't support anything more than linear https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c#n142

18:41 <CounterPillow> Seemingly only the overlay planes support afbc

18:41 <alyssa> CounterPillow: Rereading that MR, it does look like rockchip and friends might be broken

18:42 <alyssa> but just like new kernels can't break old userspace, we try pretty hard to ensure new userspaces won't break old kernels

18:42 <CounterPillow> I see

18:43 <alyssa> (for some value of old. it's not "forever", but long enough that if the issue is in user's hands, it's too late :p)

18:44 <CounterPillow> Among all the things I want to look into I'll add "fix rockchip's drm driver" to the list then, it would also be nice if plasma started using the plane that supports afbc though because specifically framebuffer updates with lots of changed pixels seem to cause hitches with panfrost occasionally right now, and I suspect memory bottlenecks

18:45 <alyssa> Might help

18:45 <alyssa> Don't discount the possibility that the hardware + software are both dogslow :-p

18:45 <CounterPillow> it seems to work better in weston (at least in supertux2)

18:46 <CounterPillow> the thing I'm observing is an application will composite smooth at 60fps as a 720p window but have a dip to <30fps every second or so for a few frames if run at 1080p

18:46 <CounterPillow> or the whole desktop has a hitch when I bring a window in the background to the foreground and it does a big repaint

18:47 <alyssa> Woof.

18:47 <CounterPillow> teeworlds is the weirdest case, where the application itself reports 60fps frametimes in GALLIUM_HUD but it's clearly not 60fps by the time it leaves the compositor

18:48 <alyssa> Related -- if vsync is disabled in Neverball, GALLIUM_HUD claims fps is 700+ but it feels about 4fps

18:48 <alyssa> because we don't yet implement context priorities

18:48 <alyssa> or preemption

18:48 <alyssa> so Neverball hogs all the GPU cycles and sway doesn't get any cycles left to actually present the frames

18:49 <cphealy> Sounds like a use case where EGL context priority would be useful. ;-)

18:50 <alyssa> Yep.

18:50 <alyssa> I might implement it if working on the kernel didn't make me feel so sad :-p

18:50 <CounterPillow> In the fullscreen teeworlds case, having working direct scanout in the compositor would probably also improve things considerably as it'd completely eliminate the job getting starved

18:51 <CounterPillow> Hmmm, apparently kwin already does direct scan-out. Well that just adds to the mystery

21:11 <alyssa> Pass (Query result verification passed)

21:11 <alyssa> Woo!

21:29 <alyssa> jekstrand: https://gitlab.freedesktop.org/alyssa/mesa/-/commit/04aa6e9d2fae7db3769c890c3d15e25728a59d4f

21:29 <alyssa> ^^ WIP but passing a few tests :)

21:31 <alyssa> CmdCopyQueryPoolResults looks really annoying to implement, since it needs a compute shader

21:31 <alyssa> (Would be perfect for the CSF MCU.......)

21:39 <jekstrand> alyssa: \o/

21:56 <anarsoul> alyssa: hm, adding context priority should be pretty straightforward, the only tricky thing is to maintain backwards compatibility

23:06 <icecream95> alyssa: Also on the topic of priorities, if I break a fragment job into 32x32 pixel tiles, then it can lock up the desktop for ages (see #6572)

23:30 <icecream95> So it appears that the cost of the larger nodearrays on RA performance is about 20% when SIMD is used, but only 15% otherwise