Re: [PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats

[Daniel Vetter <daniel@ffwll.ch>]

On Thu, Nov 07, 2019 at 09:30:50AM -0800, Eric Anholt wrote:
> Rob Clark <robdclark@gmail.com> writes:
> > On Wed, Nov 6, 2019 at 3:26 PM Fritz Koenig <frkoenig@google.com> 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@google.com>
> >
> > Reviewed-by: Rob Clark <robdclark@gmail.com>
> 
> 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@ffwll.ch>

Cheers, Daniel

> 
> Reviewed-by: Eric Anholt <eric@anholt.net>



> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch