We just moved Kodi (http://kodi.tv/) from glx to egl. With vsync enabled glx was used to block in glxSwapBuffers. EGL shows timing issues. Instead of blocking in eglSwapBuffers it blocks in subsequent gl calls like glColor for several ms. It even does so if I put a glFinish right after eglSwapBuffers. Rendering overlays on top of video leads to missed frames because it slows down rendering even more.
using gles make no difference. verified with Hello_triangle available here: https://code.google.com/p/opengles-book-samples/source/browse/trunk/LinuxX11/#LinuxX11%2FChapter_2%2FHello_Triangle measurements around eglSwapBuffers show that it does not block there.
Can you try adding INTEL_DEBUG=perf and see if anything obvious shows up?
I don't see anything obvious. I tried syncing to vertical retrace manually using drm. When I wait for a vblank and then call eglSwapBuffers, the gl functions seem not blocking anymore. IMO eglSwapBuffers behaves strange.
@Ben: Is there anything else we can provide so that this issue can be reproduced on your side?
Is this still an issue? When reading the description my wild guess is that this is related to 'intel_prepare_render'. Swapbuffers does not trigger new buffer retrieval but it is done 'lazily' only when buffers are really needed (next clear/draw as example). In a nutshell there are different points in the driver that trigger updating the render buffers and this takes some time depending on the window system and protocol used. If the subsequent frames are very different in their content this might happen at different points of time.
For a multithreaded application like Kodi it is still an issue. For deterministic behaviour an app should know where the render thread blocks. For 24fps content this is 41ms. We kind of worked around the issue by making sure the render thread does not hold any locks when making calls to GL/EGL.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1487.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.