Output of gl-renderer is incorrect

Pekka Paalanen pekka.paalanen at collabora.com
Fri Apr 12 08:17:55 UTC 2024


On Fri, 12 Apr 2024 07:44:43 +0000
"Namit Solanki (QUIC)" <quic_nsolanki at quicinc.com> wrote:

> 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?

Yes. Currently upstream Weston (and version 10) always puts the
GL-renderer rendered framebuffer on the primary KMS plane, if
GL-renderer is needed for that screen update. There can be any number
of other KMS planes on top of the primary KMS plane.

Regardless of KMS plane assignments, if GL-renderer is used, the
resulting GL-renderer framebuffer must be fully opaque.

These are indeed quite limiting, which why the work is on-going.


Thanks,
pq


> 
> 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

-------------- 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/20240412/10d4f452/attachment.sig>


More information about the wayland-devel mailing list