On Wed, 18 Oct 2023 09:18:45 +0200 Emmanuel Gil Peyrot <linkma...@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
pgpP4a7d6mYQ7.pgp
Description: OpenPGP digital signature
