12:19 <heeen> lynxeye: thanks for that insightful answer last week

12:20 <heeen> lynxeye: any suggestions what one can do to improve the situation?

12:20 <heeen> I suppose I could hand out special buffers from the compositor that lets certain applications render on a different fbdev plane and have it hardware composited?

13:45 <cphealy> heeen: Have you considered using weston as compositor instead of Qt and then running Qt apps as Wayland clients with Weston? Weston has some performance benefits over Qt as the compositor such as support for HW planes and dmabuf-feedback.

15:02 <heeen> we decided on a qml compositor for this project. I did consider it originally. performance is not critical right now, but if theres some low hangig fruits I'd like to know them

15:03 <heeen> cphealy: dmabuf-feedback - what is it? I am using QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=linux-dmabuf-unstable-v1 which is required for the buffers to be rendered

15:03 <heeen> correctly

15:11 <cphealy> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8

15:13 <cphealy> With the i.MX6q, the display controller only supports linear buffers, but the default output of the GPU is tiled. With dmabuf-feedback, there are performance optimizations such as being able to detile on render when appropriate. By default, IIRC, regardless of the framerate of the app, detiling will be done at VSYNC rate by compositor which for any time that your app is rendering at <60Hz is suboptimal.

15:13 <cphealy> (Lucas, am I getting any of this wrong?)

15:16 <cphealy> Additionally, if you have 1 fullscreen surface and 1 partial screen surface and the partial screen surface is being updated at a higher freq than the fullscreen surface, using HW planes (which weston supports) should result in a lower load on DRAM throughput and GPU.