Output of gl-renderer is incorrect

[Namit Solanki (QUIC)]

Hi pq,

Thanks for your reply. Yes, we do have downstream patches.

>From your reply, does it mean that GL-renderer rendered KMS plane can be behind Video KMS plane?

Thanks,
Namit

-----Original Message-----
From: Pekka Paalanen <pekka.paalanen at collabora.com> 
Sent: Wednesday, April 10, 2024 3:57 PM
To: Namit Solanki (QUIC) <quic_nsolanki at quicinc.com>
Cc: wayland-devel at lists.freedesktop.org; Pritama Biswas (QUIC) <quic_pritbisw at quicinc.com>
Subject: Re: Output of gl-renderer is incorrect

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