00:35 <tlwoerner> i'm getting a kernel oops on the igt test [panfrost_submit] on the rock-pi-4b (T860)

00:39 <tlwoerner> https://paste.ee/p/dG7yT

09:00 <icecream95> ndufresne: "we need someone to RE AFBC completely". Just over a year ago I mostly worked out the format, see https://gitlab.freedesktop.org/icecream95/afbc

09:16 <icecream95> alyssa: If you add a new modifier, you might as well add a bit for whether there is CRC data at the end of the BO. Maybe also some way to synchronise checksumming state, but that's unlikely to be a problem for applications that don't do crazy things

10:07 <icecream95> ndufresne: YTR does not use subsampling, and the U and V channels are stored with N+1 bits, so it is lossless

10:07 <icecream95> Swapping the U and V channels in the AFBC bitstream would have the effect of swapping R and B in the decompressed image.

10:07 <icecream95> "YUV-like" is very approximate because it's all integer math.

10:07 <icecream95> A very approximate description of AFBC is that it stores, per-channel, differences between pixel values within 4x4 blocks

10:07 <icecream95> Larger differences take more bits to represent.

10:08 <icecream95> YTR will make large changes in luminance mostly affect the Y channel, so the U and V channels will have small differences and use fewer bits

10:08 <icecream95> (Alpha, if present, is stored identically to other channels except for an optimisation for opaque blocks)

10:08 <icecream95> alyssa: "it's just compressing unorm8 blocks". Nope; RGB565 uses fewer bits for some fields compared to RGB888

10:08 <icecream95> I don't know exactly how depth is stored, but IIRC it's somewhat different again.

12:29 <ndufresne> icecream95: very nice work

12:29 <ndufresne> as it's lossless, random swapping could mostly affect compression ratio, so from what I read here, we could have to try and make clever decisions

12:30 <ndufresne> ideally if we can avoid swapping G, the resuting Y will be less affected, and we'll maintain a better compression