AW: wayland: wrong tiling with wl_drm on Vivante GC2000
Hi, Lucas! Thanks for the explanation. That fits the mental model I've built up. As it turned out it was the Wayland client computing and displaying the FPS counter which reduced the FPS in the first place. Contrary to what I initially said the FPS reduction was also present using wl_drm (I got some numbers confused). With the compositor itself doing the FPS computation both protocols (wl_drm and dmabuf) show similar FPS numbers and low CPU usage. Christian
Re: wayland: wrong tiling with wl_drm on Vivante GC2000
Hi Christian, Am Donnerstag, dem 30.03.2023 um 19:54 + schrieb Christian Gudrian: > Hi, Daniel! > > Thanks for your reply. > > > You need to force QtWayland to use the wp-linux-dmabuf-v1 platform > > integration for the compositor. > > Yes. I've did that before and that indeed solves the tiling problem. > However the CPU usage is much higher and the FPS drops from 60 to 30 > (I can see a similar behavior with Weston). etnaviv simply does not have any sideband channel to communicate the the tiling information, which would be required to make wl_drm work with tiled buffers. Falling back to linear buffers is also not an option for performance reasons. etnaviv requires a modifier enabled interface to get the tiling correct, which in the wayland case is the linux dmabuf protocol. If you see a big difference in CPU usage between the two interfaces, it would be good to investigate where this increased overhead is coming from to see if we can just fix that. Regards, Lucas
AW: wayland: wrong tiling with wl_drm on Vivante GC2000
Hi, Daniel! Thanks for your reply. > You need to force QtWayland to use the wp-linux-dmabuf-v1 platform > integration for the compositor. Yes. I've did that before and that indeed solves the tiling problem. However the CPU usage is much higher and the FPS drops from 60 to 30 (I can see a similar behavior with Weston). Christian
Re: wayland: wrong tiling with wl_drm on Vivante GC2000
Hi Christian, On Thu, 30 Mar 2023 at 20:15, Christian Gudrian wrote: > We're running a custom Wayland compositor based on Qt Wayland on an i.MX6 > Quad system with a Vivante GC2000 GPU using the Mesa Gallium driver. While > the compositor itself displays correctly, client buffers are displayed with > wrong tiling. > > So far I've found out, that the client's __DRIimage is created by > etna_resource_create with a tiled layout. This image is later passed to > create_wl_buffer which ignores the tiling information and passes the > image's FD to wl_drm_create_prime_buffer. > > If I patch etna_resource_create to always use a linear layout the client's > buffer is displayed correctly. That's certainly not how to do it correctly. > Is there a way to ensure a linear layout for this use case? > You need to force QtWayland to use the wp-linux-dmabuf-v1 platform integration for the compositor. All the others do this automatically but Qt requires an environment variable for this. Cheers, Daniel
wayland: wrong tiling with wl_drm on Vivante GC2000
Hello! We're running a custom Wayland compositor based on Qt Wayland on an i.MX6 Quad system with a Vivante GC2000 GPU using the Mesa Gallium driver. While the compositor itself displays correctly, client buffers are displayed with wrong tiling. So far I've found out, that the client's __DRIimage is created by etna_resource_create with a tiled layout. This image is later passed to create_wl_buffer which ignores the tiling information and passes the image's FD to wl_drm_create_prime_buffer. If I patch etna_resource_create to always use a linear layout the client's buffer is displayed correctly. That's certainly not how to do it correctly. Is there a way to ensure a linear layout for this use case? Christian
