Re: Graphics performance on wayland vs eglfs

["Marius Vlad" <marius.vlad@xxxxxxxxxxxxx>]

On 2/9/22 9:44 AM, Risto Avila wrote:
> Hello,
> 
> I think that it is expected to get better performance out of Qt rendering with EGLFS instead of having compositor in the middle.
> With EGLFS Qt can directly render to the screen but without it it would cycle through Weston (or what ever compositor is used) causing separate buffers being composited.

Even with the middle layer, like wayland, in some
circumstances/use-cases, I would expect similar performance.

The client creates the buffers, and it handles them out to the
compositor. It will get back an event from the compositor when it is
ready to draw. Yeah, it is compositor job to stitch  all images together
into a single image, and hand it out the display unit for rendering.
Doing that requires a renderer, sometimes using the CPU, but most often,
using the GPU.

> 
> One way to optimize the performance is replace the reference compositor with your own which can be easily done with Qt Wayland compositor API's or by using Qt Application Manager.
>  you to have 1st claBoth allowsss rendering (directly to screen using EGLFS) and 2nd class rendering through Wayland. In this case only the parts that would be using 2nd would suffer from the extra cycle.

I think I mentioned this before, the compositor can, and some of the do,
make use of the HW to such that it attempts to place the client's
buffers into a HW plane for direct scanout.

This would help out massively in terms of memory bandwidth. This
obviously happens only in some certain circumstances: fullscreen, pixel
format, etc.

Also, like Wayland, EGL is neither a drawing API. This is about the
client, not about the windowing system.

If you're using another wayland compositor you have the same thing, like
with any other wayland compositor. Yeah, most likely the Qt toolkit has
some private extensions such that maybe it can hint the compositor to
avoid any GPU imports whatsover and just hand it over to KMS. Weston has
one as well.

How much sense would it make to replace the compositor with another just
to run one single application?

> 
> How well something works depends from GPU and GPU Drivers e.g. I've seen use cases where proprietary Vivante drivers have been faster than etnaviv and vice versa.
> In any case single full screen rendering will be fastest if you do it directly with GPU without separate compositor in the between.

As the client does the drawing, with a GLES/GL/Vulkan drawing API, it is
receiving frame callbacks on when to draw, it shouldn't really incur
drastic penalties.

Circling back to your first paragraph, for instance, for a fullscreen
application I would expect similar performance, due to the fact that
everything underneath it is being discarded, while the compositors
attempts to
make use a HW plane for a direct scan-out.

> 
> Best regards,
> Risto Avila
> 
> ________________________________
> From: agl-dev-community@xxxxxxxxxxxxxxxxxxxxxxxxx <agl-dev-community@xxxxxxxxxxxxxxxxxxxxxxxxx> on behalf of Marius Vlad via lists.automotivelinux.org <marius.vlad=collabora.com@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Sent: Tuesday, February 8, 2022 16:43
> To: agl-dev-community@xxxxxxxxxxxxxxxxxxxxxxxxx <agl-dev-community@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Re:  Graphics performance on wayland vs eglfs
> 
> Wrt to the cluster question, see Scott's answer:
> 
> https://lists.automotivelinux.org/g/agl-dev-community/message/9626
> 
> 
> On 2/8/22 2:41 PM, Paulo Sherring wrote:
>> Hello all,
>>
>> I am working (more accurately playing around) on an Instrument Cluster
>> application. I am currently based on master and it is basically the same IC
>> application we had in past branches.
>> I am currently experimenting with GFX (effects, animations, fade in, fade
>> out) and video playback.
>>
>> One thing that I noticed is that if I don't use Wayland (i.e., no
>> running compositor and passing QT_QPA_PLATFORM=eglfs), I get much smoother
>> graphics, so much that it is visible to the eyes: smoother opacity
>> changing, smoother video playback, visual effects such as QML Glow becomes
>> really efficient.
>>
>> So, my question is: is there a way of getting eglfs equivalent performance
>> when using Wayland?
> 
> 
> This is quite vague, I guess some real numbers could tell how much of a
> difference you're seeing between the two. With mesa drivers you could
> use GALLIUM_HUD=cpu,fps and have a look at both. Probably that's
> possible with rpi4 but probably not with r-car. Same with vivante vs
> etnaviv. What platform you're using? Are you sure you're using the GPU
> and not llvmpipe/softpipe?
> 
> Itself wayland is just a protocol not a drawing API so there's nothing
> to make it much for faster, than it currently is. Not really sure what
> to recommend at this point, but I guess a difference between the two is
> the fact that with Wayland you have multiple clients
> and you have composite imagine, while with eglfs you have a single,
> full-screen application. But even so,
> compositors attempts to make use of the HW, if available, just like
> probably happens with eglfs and the KMS backend.
> 
> It is rather hard at this point to tell, without some specific use-cases
> to compare and more information on the matter.
> 
>>
>> BTW, in regards to IC images on the master branch, do we still get
>> agl-cluster somehow? If not, will we get it again? I couldn't find it on
>> master nor on the docs and proceedings.
>>
>> Kind regards,
>> Paulo Sherring.
>>
>>
>>
>>
>>
>>
> 
> --
> Marius Vlad
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Marius Vlad


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9664): https://lists.automotivelinux.org/g/agl-dev-community/message/9664
Mute This Topic: https://lists.automotivelinux.org/mt/88995048/2167316
Group Owner: agl-dev-community+owner@xxxxxxxxxxxxxxxxxxxxxxxxx
Unsubscribe: https://lists.automotivelinux.org/g/agl-dev-community/leave/4543822/2167316/883735764/xyzzy [list-automotive-discussions82@xxxxxxxxxxx]
-=-=-=-=-=-=-=-=-=-=-=-