> If YTR can't be turned off, then according to the AFBC spec - correct.
There is no public AFBC spec, so I'm not sure how to respond to this.
> If the hardware allows it to be configured to use YTR with other
> component orders, I don't know exactly what the impact would be -
> maybe nothing.
It's legal to use YTR with a BGR framebuffer regardless of the content
of the framebuffer, yes? Could I postprocess with the following shader?
void main() {
vec4 colour = ....;
gl_FragColor = colour.bgra;
}
That's just 3D rendering. But now if I feed that rendered "BGR"
framebuffer in I get the illusion of RGB out.
Doing the colourspace conversion in hardware (with the
GPU's component reordering) is mathematically indistinguishable from
rendering BGR with that shader.
I sympathize with reducing AFBC's combinatoric explosion, and I realize
that the Rockchip VOP is probably wrong. I also realize that the
transform is defined for BGR inputs, not RGB ones, so it might be
slightly less effective for real content. But it seems to me allowing
both BGR+YTR and RGB+YTR upstream is the better route than simply
preventing hardware from using AFBC at all, and there are natural
encodings for both with fourcc modifiers.
Maybe there's a deeper reason to require BGR that I'm missing? Please
let me know if I've misunderstood, I only know AFBC from the GPU side.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
