aritger / eglstreams-kms-example

Example of using EGLStreams + DRM KMS
MIT License
60 stars 18 forks source link

Hanging at second eglSwapBuffers #6

Open lukexi opened 7 years ago

lukexi commented 7 years ago

On Arch, kernel 4.11.2-1-ARCH with Nvidia 381.22, the executable manages to launch and render a single frame, but then hangs upon the second call to eglSwapBuffers().

lukexi commented 7 years ago

Just tried out aplattner's weston-eglstreams build and it runs beautifully. I'll see if I can glean something from that.

lukexi commented 7 years ago

This seems to be an issue with either Kernel 4.11 or Nvidia driver 381.22 — downgrading to Kernel 4.9.6 + Nvidia 375.26 resolved the issue.

lukexi commented 7 years ago

This still occurs with Nvidia 384.69 on Kernel 4.12.10.

A possible clue: if I put in a usleep(16000) or so (roughly VSync interval or higher) after the eglSwapBuffers call, I can make it through 150 frames without hanging. But I still eventually hang : p

lukexi commented 7 years ago

(I'm now a bit stuck since we need to upgrade our Nvidia driver to fix kernel panics with multiple displays on some of the Zotac EN1060 boxes we use, but then we run into this hanging issue instead.)

mvicomoya commented 7 years ago

@lukexi, sorry I missed this in the first place. This is a known issue in our EGLOutput auto-acquire mode implementation. We are actively working to resolve it.

I'm not sure what is your actual use case, but it is highly advisable that you make use of EGL_NV_output_drm_flip_event extension instead of relying on auto-acquire. That is what we use in our weston and mutter wayland EGLStream backends.

Feel free to reach out to me if the extension language and/or weston code isn't clear enough to get your code to use EGL_NV_output_drm_flip_event.

lukexi commented 7 years ago

OK, thanks Miguel! Great to have that info — I'd taken a look at the weston/mutter code briefly but didn't put in the effort to extract how to use EGL_NV_output_drm_flip_event; I'll put in more now that I know it's a good way to go.

It would definitely be helpful to see an example integrated into this repository's code!

The other thing that would be super helpful is how to get this to interact smoothly with multiple monitors displaying independent content; with my current code adapted from here on 375.26 I end up locked to some subdivision of VSync when rendering to multiple displays on a single thread. (e.g. 30hz when rendering to 2 60hz displays — ideally I'd like to render to 4 displays each properly vsync'd to refresh rate).

My attempt to multithread with a GL context & display per thread just seemed to introduce a lot of resource contention, but maybe I'm doing something wrong.

Is there a recommended approach or some sample code I can look at for that?

lukexi commented 7 years ago

OK, I've sussed out EGL_NV_output_drm_flip_event and see how I can use drmHandleEvents now to get exactly the behavior I want for multi-monitor VSync as well without blocking or adding threads. Thanks much for the pointer!

lukexi commented 7 years ago

I've put up a minimal example of EGL_NV_output_drm_fip_event usage here that works on 384.69: https://github.com/lukexi/eglstreams-mini

As mentioned to Miguel in email, this works well for a single display but still exhibits an issue with blocking in the stream frame acquire when using multiple displays (so I can only achieve e.g. 30FPS with 2 monitors).

lukexi commented 7 years ago

weston-eglstream also seems to tank in frame rate when using multiple monitors.