On Thu, Nov 07, 2019 at 09:30:50AM -0800, Eric Anholt wrote:
> Rob Clark <robdclark@xxxxxxxxx> writes:
> > On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig <frkoenig@xxxxxxxxxx> wrote:
> >>
> >> Hardware only natively supports BGR8888 UBWC.
> >> UBWC support for RGB8888 can be had by pretending
> >> that the buffer is BGR.
> >
> > Just to expand, this aligns with how we handle RGB component order in
> > mesa for tiled or tiled+ubwc. If uncompressed to linear the component
> > order is RGB, but in tiled or tiled+ubwc, the component order is
> > always the hw "native" order (BGR) regardless of what the outside
> > world thinks. But that detail kinda doesn't matter, it's not like
> > generic code is going to understand the tiled or tiled+ubwc format in
> > the first place.. and code that does understand it, knows enough to
> > know that tiled/tiled+ubwc is always in the native component order.
> >
> >> Signed-off-by: Fritz Koenig <frkoenig@xxxxxxxxxx>
> >
> > Reviewed-by: Rob Clark <robdclark@xxxxxxxxx>
>
> Seems like a reasonable workaround to me, and permissible by our fourcc
> modifier rules ("you just have to have one way to address the pixels
> given a fourcc and a modifier").
Yeah we have some other aliasing going on already I think. And since for
interopt you just need to pick matching (fourcc, modifier) pairs worst
case that means drivers need to add a bunch of dummies/duplicates. Like we
do here.
Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
Cheers, Daniel
>
> Reviewed-by: Eric Anholt <eric@xxxxxxxxxx>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
