On Fri, 12 Apr 2024 07:44:43 +0000 "Namit Solanki (QUIC)" <quic_nsola...@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.paala...@collabora.com> > Sent: Wednesday, April 10, 2024 3:57 PM > To: Namit Solanki (QUIC) <quic_nsola...@quicinc.com> > Cc: wayland-devel@lists.freedesktop.org; Pritama Biswas (QUIC) > <quic_pritb...@quicinc.com> > Subject: Re: Output of gl-renderer is incorrect > > On Mon, 8 Apr 2024 06:42:34 +0000 > "Namit Solanki (QUIC)" <quic_nsola...@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
pgpDr0QFccwQd.pgp
Description: OpenPGP digital signature
