Bug 91395 - OpenGL functions block for serveral ms when used with EGL
Summary: OpenGL functions block for serveral ms when used with EGL
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2015-07-19 11:41 UTC by Rainer Hochecker
Modified: 2019-09-25 18:54 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Rainer Hochecker 2015-07-19 11:41:19 UTC
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.
Comment 1 Rainer Hochecker 2015-07-20 16:11:16 UTC
using gles make no difference. verified with Hello_triangle available here:

measurements around eglSwapBuffers show that it does not block there.
Comment 2 Ben Widawsky 2015-07-25 15:07:59 UTC
Can you try adding INTEL_DEBUG=perf and see if anything obvious shows up?
Comment 3 Rainer Hochecker 2015-07-25 15:31:39 UTC
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.
Comment 4 Peter Frühberger 2015-11-27 20:47:55 UTC
@Ben: Is there anything else we can provide so that this issue can be reproduced on your side?
Comment 5 Tapani Pälli 2017-01-09 12:37:22 UTC
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.
Comment 6 Rainer Hochecker 2017-01-15 08:01:49 UTC
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.
Comment 7 GitLab Migration User 2019-09-25 18:54:06 UTC
-- 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.