Just wanted to demonstrate how PNG is not inherently serial.
Well, you bought it for a hell lot of routing.
If, say you implement it as a pipeline what you were drawing, and you can manage an outstanding queue, you might actually get away with 2 cycles sustained throughput per tile, which would be very nice. But I have my doubts that this implemention matches the latency requirements of the render feedback loop (I mean tiles circulating between raster-output and memory). I suspect you can't give away any cycle of added latency, or otherwise: "do it again".
Sure, the approach is always the same for this stuff (depth buffer, MSAA etc), when you overflow you just drop to baseline uncompressed.
If the delta values fit into 2bits you go say 1:8, otherwise when 3bit then 1:4, when 4bit 1:2 otherwise dump 1:1. It's never really cheap to figure the right permutation for the encoding, but if it's within 4-8 cycles per tile, it might be in a better place than the above pipelined implementation.
The acceptability very much depends on the exact statistical profile of the ROP-cache/MC transfers. An implementation might just give a damn about latency because tiles are ever only re-touched every 1k cycles. Or if going to memory already takes 400 cycles, what does it matter if we add 50-100 more. There might be a window where you can pick a dog-slow implementation, like with XB1 zlib compression. If that thing would be serial, or you have to use it serial, it's a killer; if asynchronous you might not care that much.
My preference though is, try to make it really tight (better safe than sorry) without forgetting about compression efficiency.
Anyway. Little bit off-topic, sorry for the distraction.
