Output of gl-renderer is incorrect

[Pekka Paalanen]

On Mon, 8 Apr 2024 06:42:34 +0000
"Namit Solanki (QUIC)" <quic_nsolanki at quicinc.com> wrote:

> Hi Weston team,
> 
> We are working on Weston 10 version. We have a use case where we are
> playing a video using Gstreamer and on top of it we are running a
> Weston-simple-egl app.
> 
> Status bar and the Weston-simple-egl layer is sent to gl-renderer for
> GPU composition and Video is sent to Display processing unit.
> 
> So finally gl-renderer's output is composed with the Video layer in
> Display processing unit. But we see that there is corruption in this
> use case.
> 
> The output of gl-renderer is having some garbage data. We dumped the
> output of gl-renderer onto a RAW file and when we open it on a image
> editor we see same corruption in the gl-renderer's output.
> 
> When we force all the layers (simple-egl + Video + Status bar) to go
> to GPU composition there is no issue.
> 
> When we run only Video there is no problem. When we run only
> Weston-simple-egl then also there is no problem. But when we run
> simple-egl app on top of Video we see this corruption.
> 
> Any pointers to debug or fix this issue will be really helpful.

Hello,

from the attached image I see that the video KMS plane is behind the
GL-renderer rendered KMS plane. This is not possible with upstream
Weston 10, so I assume you must have downstream patches applied to make
this happen. I can only guess that the downstream patches you use are
not complete.

Both GL-renderer and the damage tracking (to render only changed areas
of a screen) assume that if a GL-renderer rendered framebuffer is used,
it will be completely opaque. The opaqueness relies on the whole screen
being fully covered with opaque weston_surfaces. Usually this is
achieved with a wallpaper or a background color fill weston_surface. If
the screen is not fully covered, incorrect rendering like traces from
moving weston_surfaces are expected. GL-renderer never clears the
framebuffers it renders to, but relies on the content opaqueness
instead, so it is also possible to see uninitialized memory contents on
areas not covered by opaque surfaces if the GL ES 2 driver does not
initialize framebuffer allocations.

I suspect that to be the most likely reason for the corruption.

There is upstream work on-going to allow video underlays in addition to
video overlays, either by KMS overlay planes below the primary plane or
by moving the renderer framebuffer to a KMS overlay plane, but that
work is not yet complete, see:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258
https://gitlab.freedesktop.org/wayland/weston/-/issues/886
https://gitlab.freedesktop.org/wayland/weston/-/issues/9


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20240410/4489423f/attachment.sig>