[Mesa-dev] mx6q: Cannot run Cinematic demo correctly

[Wladimir J. van der Laan]

On Tue, Mar 14, 2017 at 06:39:32PM +0100, Christian Gmeiner wrote:
> > By only reverting:
> >
> > commit 6c89a728d9e5d072cb504453e73077564c6523d3
> > Author: Wladimir J. van der Laan <laanwj at gmail.com>
> > Date:   Wed Dec 7 12:59:54 2016 +0000
> >
> >     etnaviv: Cannot render to rb-swapped formats
> >
> >     Exposing rb swapped (or other swizzled) formats for rendering would
> >     involve swizzing in the pixel shader. This is not the case at the
> >     moment, so reject requests for creating such surfaces.
> >
> >     (GPUs that need an extra resolve step anyway due to multiple pixel
> >     pipes, such as gc2000, might also do this swap in the resolve operation.
> >     But this would be tricky to keep track of)
> >
> >     CC: <mesa-stable at lists.freedesktop.org>
> >     Signed-off-by: Wladimir J. van der Laan <laanwj at gmail.com>
> >     Acked-by: Christian Gmeiner <christian.gmeiner at gmail.com>
> >
> > I can confirm that the Cinematic demo can run successfully. I do not
> > see the black boxes, nor font issues anymore.
> >
> 
> I am a little bit overloaded with my day job (again) and the initial plan was to
> land something in stable for 17.0.1 release failed - but he 17.0.2 will come.
> 
> >
> > Also the previous error messages are gone:
> > QOpenGLFramebufferObject: Unsupported framebuffer format.
> > QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
> > QOpenGLFramebufferObject: Unsupported framebuffer format.
> > QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
> > QOpenGLFramebufferObject: Unsupported framebuffer format.
> > QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
> > QOpenGLFramebufferObject: Unsupported framebuffer format.
> > QOpenGLFramebufferObject: Framebuffer incomplete, missing attachment.
> >
> > as to your other patch: I do not see commit
> > 89bb5c79e29613ad9a4e43d670654e98a220fc60 in mesa tree.
> >
> > Wladimir/Christian,
> >
> > What would be the proper fix for this problem?
> >
> 
> shader variants - due to lot of people are have this issue I will
> spend some time the next
> days to cleanup my wip patch series. I have too may concurrent etnaviv
> work items running
> in parallel :(

Yea, variants would be the way to render to RGBA succesfully
on vivantes.

Until then it's best to revert those two patches.

Reverting only the one (latest) patch can give red/blue swapped issues when
doing render-to-texture, it was applied in the first place to fix those issues
caused by the first patch, but it didn't really make things better.

Wladimir