RE: Output of gl-renderer is incorrect
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 Sent: Wednesday, April 10, 2024 3:57 PM To: Namit Solanki (QUIC) Cc: wayland-devel@lists.freedesktop.org; Pritama Biswas (QUIC) Subject: Re: Output of gl-renderer is incorrect On Mon, 8 Apr 2024 06:42:34 + "Namit Solanki (QUIC)" 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
Re: Output of gl-renderer is incorrect
On Fri, 12 Apr 2024 07:44:43 + "Namit Solanki (QUIC)" 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 > Sent: Wednesday, April 10, 2024 3:57 PM > To: Namit Solanki (QUIC) > Cc: wayland-devel@lists.freedesktop.org; Pritama Biswas (QUIC) > > Subject: Re: Output of gl-renderer is incorrect > > On Mon, 8 Apr 2024 06:42:34 + > "Namit Solanki (QUIC)" 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
Xwayland 24.1 branching and schedule
Hi all In preparation for the forthcoming Xwayland 24.1.0 release, I've now created the xwayland-24.1 branch: https://gitlab.freedesktop.org/xorg/xserver/-/tree/xwayland-24.1 And there's also a milestone that can be used to tag issues and merge requests targeting Xwayland 24.1.0: https://gitlab.freedesktop.org/xorg/xserver/-/milestones/17 We are already quite late in the year so for schedule, I would like to start as soon as next week, and an RC every two weeks: * April 17th, 2024: Xwayland 24.1.0 RC1 * May 2nd, 2024: Xwayland 24.1.0 RC2 * May 15th, 2024: Xwayland 24.1.0 (if all goes well) Cheers Olivier
