00:20 <alyssa> I wonder if the DDK's Valhall scheduler tries to "balance" the pipes.

00:21 <alyssa> Certain instructions have equivalents on other pipes. Rewriting to balance the utilization of each functional unit improves throughput *in theory*.

00:21 <alyssa> I have no idea if that works in practice.

00:22 <alyssa> Or if it matters in practice ... there's not many nonorthogonal instructions on Valhall to make that useful.

00:22 <alyssa> (Compare Bifrost which has tons, and schedule quality depends on doing this trick)

00:24 <icecream95> alyssa: bi_clper_xor is broken on G31...

00:25 <icecream95> So I guess you don't have to do so much G31 bugfixing yourself now

00:26 <alyssa> icecream95: It's not broken, it doesn't exist.

00:26 <alyssa> Found that one out the hard way.

00:26 <icecream95> No, I mean the C function bi_clper_xor

00:26 <alyssa> Oh, ffs

00:26 <alyssa> fricking

00:26 <alyssa> fuck

00:27 <alyssa> patch incoming

00:28 <icecream95> Okay sure I'll let you increase your patch count then

00:28 <icecream95> Possibly Closes: #6550

00:30 <alyssa> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16846

00:31 <alyssa> look zmike is ahead of me :V

00:32 <icecream95> alyssa: But mind your language. There could be minors on the channel, they might not know what those words mean

00:33 <alyssa> "fricking"?

00:33 <alyssa> It's a typo, you know how many typos i make

00:33 <alyssa> Meant to say "fracking"

00:33 <alyssa> It's a controversial way of getting oil

00:34 <alyssa> :p

00:34 <icecream95> No, find first set. *shudders*

00:35 <alyssa> Uh

00:35 <alyssa> clz

00:35 <alyssa> pardon my gcc

00:35 <icecream95> *gasp*

00:37 <alyssa> icecream95: By the way, "CLPER_V6" is named like that because, at the time, we saw it with G72 but not G52 and assumed it was an arch issue

00:37 <alyssa> Then I tried running deqp on g31...

00:38 <alyssa> should maybe rename to CLPER_OLD?

00:39 <icecream95> CLPER_TOENAILS?

00:40 <alyssa> :thinking_face:

01:17 <icecream95> I wonder... is there any reason that we can't use AFBC for at least DXTn texture formats?

01:18 <icecream95> It's possible that doing that would be able to get at least *some* compression, but probably the GPU wouldn't be able to handle it, so...

01:19 <icecream95> (That is, AFBC-compressing the actual block-compressed data)

01:21 <icecream95> But panfrost_afbc_format should probably be expanded to handle more formats, like R8_UNORM

01:22 <icecream95> I think sRGB should also be added to workaround crashes with Gallium HUD

02:19 <cphealy> icecream95: with AFBC, the RAM requirements are the worst case which is no compression + metadata while texture compression formats such as DXTn are lossy and come with the benefit of smaller RAM requirement. What would the benefit be of using AFBC for DXTn textures?

02:22 <icecream95> cphealy: I was thinking of doing AFBC on the already-compressed DXTn data, but the GPU probably doesn't support that, and it wouldn't work that well anyway

02:22 <icecream95> And my patches to reduce RAM requirements for AFBC have been working pretty well for a while now, I just need to find the time to upstream them...

03:38 <cphealy> icecream95: I'm not aware of your patches to reduce RAM requirements for AFBC, can you point to the patches?

03:49 <anarsoul> alyssa: ping

03:49 <anarsoul> alyssa: so I tried dEQP-GLES2.functional.multisample.* on panfrost and it passes just fine on surfaceless

03:49 <anarsoul> alyssa: does it do any tricks with msaa like always doing in-place resolve?

04:10 <anarsoul> trace says "Writeback MSAA: Layered"

08:37 <icecream95> Hmm... so either pandecode_dump_mappings is completely broken, or AFBC has a mode for compressing gradients which I've never heard of

08:38 <icecream95> My guess is that it is the former

08:38 <icecream95> sigh, we really need better tools for exploring dumps

08:40 <icecream95> Heavily using SQLite, of course

09:15 <HdkR> Gotta eat those 3ms/commit times on every sqlite entry addition :P

21:50 <cphealy> alyssa: Some week or two back you posted this showing perf counter data: https://rosenzweig.io/mh.txt Is there any public code for this that I can experiment with?

21:51 <alyssa> all of my code is public because i can't be trusted not to dd if=/dev/urandom of=my rootfs

21:51 <alyssa> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16803/diffs?commit_id=fda146300d8a8341bd56911d54fafb725e5fdad5

21:51 <alyssa> note the license

22:07 <cphealy> I must be missing the license

22:07 <cphealy> Or is that the point? ;-)

22:13 <cphealy> alyssa: Thank you!

22:13 <cphealy> this looks very useful

22:19 <FLHerne> I guess if there's no specific license, it's covered by the default MIT one in docs/license.rst?