Hi,
We are currently investigating a rendering stall that appears to be related to NV_SWAPINTERVAL in a Wayland environment, and would appreciate any guidance.
Setup:
- Qt-based application
- Wayland platform
- NVIDIA Wayland EGL graphics driver
Observed behavior:
- With NV_SWAPINTERVAL=0, the application runs without issues
- With NV_SWAPINTERVAL=1, the application occasionally enters a blocking state that does not recover
When the issue occurs, the following call stack is observed:
eglSwapBuffers()
→ libEGL.so.1
→ libnvidia-egl-wayland.so.1
→ wl_display_dispatch_queue()
→ poll()
This seems to indicate that the thread is waiting in the Wayland event dispatch path during buffer swapping.
We would like to better understand if this behavior could be related to the expected operation of NV_SWAPINTERVAL=1 under Wayland.
Specifically:
- Is NV_SWAPINTERVAL=1 expected to synchronize rendering via vblank or compositor frame callbacks?
- In such cases, is it normal for eglSwapBuffers() to block while waiting for these events?
- Are there known situations where this wait might not resolve, for example due to missing callbacks or surface state changes?
- If so, are there any recommended configurations or best practices to avoid this kind of blocking?
We are trying to understand whether this aligns with expected behavior or known limitations.
Any insight or guidance would be greatly appreciated.