Sub 16ms render but missing swap

[Pekka Paalanen]

On Wed, 18 Oct 2023 09:18:45 +0200
Emmanuel Gil Peyrot <linkmauve at linkmauve.fr> wrote:

> Hi,
> 
> On Wed, Oct 18, 2023 at 12:00:45AM +0000, Joe M wrote:
> > In a GLES app wired up to Weston/Wayland using EGL, we're calling
> > `eglSwapBuffers` in a render loop that takes about 12-13ms to draw
> > our content, based on CPU timing the run loop. However, the call to
> > swap incurs a duration of around 20ms, meaning we're only hitting
> > 30fps.  
> 
> Most GPUs nowadays aren’t synchronous, your driver creates command
> buffers which are sent to the GPU asynchronously, and then the GPU
> does its work.  But unless you call glFinish() or wait on a sync
> object, you won’t know at which time the GPU is actually done
> executing your commands.  Most notably, eglSwapBufers() will not wait
> until your buffer is fully drawn, so that you can start preparing for
> the next frame ahead of time.

Indeed, this is probably the explanation here.

If the CPU already takes 12-13 ms before eglSwapBuffers submits that
work to the GPU, then the GPU has fairly little time left to finish its
work if you intend to not miss the flip deadline to keep up with 60 Hz.

If Weston is compositing with GL ES, then also Weston's compositing GPU
job needs to finish before the deadline, not only the application's.
OTOH, Weston's compositing work is usually simple blits, so it's
usually fast unless your bottleneck is GPU memory bandwidth.

> > I've investigated a little bit into using the presentation callback
> > protocol, but my understanding is that the EGL display (part of
> > drm-wayland in the mesa source IIRC) is itself already plugged in
> > to the necessary Wayland callbacks such that using `eglSwapBuffers`
> > is sufficient to maximize available draw time. I also tried
> > enabling the profile flag in weston.ini that allows you to collect
> > a trace, viewable in *wesgr*.  And I read Pekka's blog posts about
> > these diagrams, but I still can't understand if our app is doing
> > something suboptimally. I can't decipher what the wesgr diagram is
> > saying. The other weston.ini knob I've tried is the `repaint`
> > window, setting it to 12 or 13 to match our drawing loop. This
> > seems to help sometimes but not in this case. A few questions:  1.
> > What other avenues of investigation should I pursue for the swap
> > delay? As in, why when I take 12 ms to render do I not see about
> > 4ms for the swap call to return? My display is running in at 60hz.
> > 2. Has EGL been optimized to use the available wayland callbacks
> > and maximize available client drawing time?

The problem is, eglSwapBuffers call is the point where the GPU usually
*starts* your rendering work. You could glFlush a part of your work
earlier, or Mesa might flush automatically at some points.

A trace for wesgr, if you compress and attach it, could perhaps
confirm this from Weston's point of view.

eglSwapBuffers itself may stall for example 20 ms, because with
eglSwapInterval 1 (the default) it will wait for your previous frame to
be taken by the compositor into its screen update, and that screen
update cannot start until the screen update before that has gone
through. Maximum screen update rate is the monitor refresh rate. So you
are likely both decimating frame rate and not maxing out GPU usage, or
in other words, the system is automatically adjusting to the vsync'd
steady framerate you *can* keep up: 30 Hz.

Weston's repaint-window setting adjusts how long Weston will wait for
app updates after the last KMS screen refresh finished before "locking"
the next screen update contents. The time of locking is the deadline
for apps to call eglSwapBuffers in order to have the possibility of
making it for the very next screen update. You can still miss the
actual screen update deadline (vblank), because even if everything has
been submitted to the GPU and Weston has submitted the screen update to
the KMS, KMS will not take that update into use until the GPU work it
depends on has finished. Once the GPU work has finished, the update can
be taken into use on the next vblank.

You could try setting eglSwapInterval to 0 in your app and check what
framerate you measure in your app. If that's still at or below 60 Hz,
then I think your app is just too heavy for the hardware to meet 60 Hz.
If it's steadily well over 60 fps, then it gets more interesting.

> >  3. Does EGL leverage
> > "weston_direct_display_v1" when available? What's required to take
> > advantage of it in the app code? (ie. run fullscreen?) Thanks!  

Mesa does not use that, and the extension is both not going to help
here, and not meant for this.

The reason it is not going to help is that whenever at all possible,
Weston will already automatically skip compositing with GL ES and just
push application buffers straight to screen via DRM KMS.

weston_direct_display is meant for content that will crash the hardware
(yes, I mean really the hardware, not software) if anything other than
DRM KMS attempts to access the pixels. IOW, it is meant for content
that is under Digital Rights Management enforced by the hardware. It
only makes the content never be composited through the GPU, but it does
not relax any requirements of composition bypass, which means it is
very easy to just get no picture at all.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20231018/cd244c21/attachment.sig>