00:12 <alyssa> steev: remind me the context?

00:13 <steev> alyssa: invalid enc

00:13 <steev> on g31

00:13 <alyssa> on which workload?

00:13 <steev> anything

00:13 <steev> running alacritty gives garbage, chrome just crashes

00:13 <alyssa> alright..

00:14 <alyssa> you know how to do a `git bisect`?

00:14 <steev> on the kernel yeah, i'm just trying to find something closer to main's main before starting

00:18 <robclark> bisecting is easier w/ mesa because no merge commits.. also the branchpoint on main gets tagged, so you can start out by checking 21.2-branchpoint to decide if you need to bisect main or the release branch

00:19 <steev> yeah, that's what i'm doing here so far, finding the newest that "works" (in quotes because again, the black text in lightdm is white, for some reason)

18:18 <alyssa> From public Arm (Vulkan) docs, Valhall supports AFBC on all formats "up to and including 32 bits per pixel reardless of color [sic] channel arrangement or sRBG [sic]"

18:19 <alyssa> from Arm Tech Day i assume that is AFBC 1.3, though I could be wrong

18:20 <alyssa> apparently Valhall also does native FP16 render targets and layered rendering, ooh

18:28 <alyssa> and from Arm blog--

18:28 <alyssa> "new features in Valhall through AFBC 1.3. include... 2-plane YUV... front-buffer rendering... separate depth/stencil encoding... opacity/transparency hints"

18:29 <alyssa> except I can't actually get the blob to do that

18:31 <alyssa> oh, just needed to crank up the size

18:31 <alyssa> with a 2048x2048 render target...

18:32 <alyssa> hm, maybe not

18:32 <alyssa> cranking up the size does get it to switch on tiled headers

20:44 <alyssa> mipmapping on valhall is the same as bifrost, afaict

20:45 <alyssa> there's a cute twist where they do AFBC tiled if rendering 128x128 or above, and do AFBC untiled below, and switch modes

20:45 <alyssa> within the miptree

20:45 <alyssa> They might also do that on Bifrost, though? never checked.

21:04 <alyssa> gl_FragCoord is more complicated than I thought

21:04 <alyssa> first they load the address:

21:04 <alyssa> unk:2C + ((r61 >> 16) & 0x3F) << 2

21:05 <alyssa> Then they convert the upper and lower halves to f32 from s16

21:06 <alyssa> And they convertthe upper and lower halves of r59 from u16 to f32

21:06 <alyssa> do some matrix math with a matrix from the uniforms to put it together

21:06 <alyssa> Given the spec definition, that other address is going to be a sample position

21:07 <HdkR> There should have been a gl_iFragCoord in the spec, truncated of course :P

21:07 <alyssa> On both Bifrost and Valhall, the third byte of r61 is the sample ID, so you can read the address as

21:07 <alyssa> uint32_t *base = (uint32_t *) unk:2C;

21:08 <alyssa> uint32_t values = base[gl_SampleID];

21:09 <alyssa> for the math -- apparently I wrote exactly this out in Panfrost already

21:09 <alyssa> util/pan_lower_sample_position.c

21:10 <alyssa> so the moral is unk:2C on Valhall is BIR_FAU_SAMPLE_POSITIONS_ARRAY on Bifrost

21:12 <alyssa> decoding that is a pretty trivial addition to the disassembelr

21:13 <alyssa> yes, this means gl_FragCoord is completely broken on bifrost too.