00:21 <alyssa> Looking at perf counters with IDVS on bump + high poly

00:21 <alyssa> execution engine is starving most of the time

00:21 <alyssa> <17% of EE time is actually doing work

00:22 <alyssa> 8% of the time is reads from the load/store pipe

00:22 <alyssa> (EE time)

00:22 <alyssa> 7% of the EE time is writes from the load/store pipe

00:23 <alyssa> 3% of the EE time is varying interpolatio

00:23 <alyssa> really not clear where the time is going. I guess memory access.

00:25 <HdkR> No counters for memory stalls?

00:25 <alyssa> I don't quite understand the memory counters

00:25 <alyssa> Read stall cycles (l2_rd_msg_in_stall): 367282887

00:25 <alyssa> Write stall cycles (l2_wr_msg_in_stall): 228086275

00:25 <alyssa> that seems.... significant.

00:26 <HdkR> Definitely big numbers at least

00:26 <alyssa> so 79% of the time we're stalled

00:27 <alyssa> wonder if the SoC is super memory bandwidth starved

01:22 <alyssa> S922x: 4.8 GiB/s

01:22 <alyssa> RK3399: 6.6 GiB/S

01:22 <alyssa> Guess that explains some cases where the rk3399 is faster

01:26 <HdkR> Need more 400GB/s ARM chips

01:26 <alyssa> brb porting panfrost to the m1 max

15:28 <cphealy> alyssa: how are you getting the counters when running glmark2? I'd like to do some comparisons on the platforms I'm working with.

15:31 <cphealy> additionally, given the relationship with memory bandwidth, it makes sense that AFBC will have a significant impact on the numbers. With AFBC today, IIRC we have YTR available but not SC (solid color). Getting SC enabled with AFBC would likely give another significant reduction in bandwidth over what we have with AFBC today.

16:55 <macc24> cphealy: i think you can use perfetto

17:12 <robclark> cphealy: https://docs.mesa3d.org/perfetto.html

17:13 <robclark> there are some example trace configs in https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/tool/pps/cfg

19:27 <cphealy> cool, tnx macc24 and robclark!

19:44 <macc24> cphealy: sure no prob, hit me up if any problems arise in anything

22:32 <alyssa> cphealy: perfetto is the 'right' way, I think

22:33 <alyssa> though for just dumping the counters at a moment in time, it's more convenient to use https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/panfrost/perf/quick.c

22:33 <alyssa> ^for me

22:34 <alyssa> compile mesa with -Dtools=panfrost

22:34 <alyssa> and it'll be in mesa/build/src/panfrost/perf/panquick

22:36 <alyssa> the SC modifier, uh, I don't know what that does.

22:36 <alyssa> I don't think it works the way you think though, the GPU will produce/consume SC blocks regardless

22:39 <alyssa> I don't know if any drivers other than mali-dp actually care about the SC modifier

22:40 <alyssa> the AFBC UABI is horribly underspecified

22:48 <cphealy> Regarding SC, my thought was that it is similar to YTR in that it can be used when scanning out to display IP with AFBC decoders supporting YTR (or SC in this case.)

22:48 <cphealy> alyssa: thanks for the details on the quick perf tool.

22:57 <alyssa> cphealy: For YTR, there is literally a bit that Mesa sets saying "use YTR" or "don't use YTR"

22:57 <alyssa> For SC, there is no such bit... Either the GPU uses SC or not.

22:57 <alyssa> I don't understand what the modifier is supposed to do.