We have been using this for years now and did not observe issues you mentioned. I would be surprised if a child window refreshes in a different rate than the main window Am 13.07.2016 11:44 schrieb "Michel Dänzer" michel@daenzer.net:
On 13.07.2016 15:50, Rainer Hochecker wrote:
Whatever action is taken, it is fine for Kodi. GLX+OML_sync_control is not an option anymore because we need EGL for vaapi. But we can fall back to the invisible window for getting vsync. I never tried using EGL and GLX in the same application, different windows. Any reason why this should not work?
An invisible window may not synchronize with the same output refresh cycle as your output window.
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
On 13.07.2016 18:49, Rainer Hochecker wrote:
We have been using this for years now and did not observe issues you mentioned. I would be surprised if a child window refreshes in a different rate than the main window
The Xorg driver decides which CRTC to synchronize with based on the window geometry. For a window with no visible geometry, it may choose a different CRTC than for the visible output window. In the case of DRI3, the Xorg Present extension code may even fall back to the fake CRTC in that case, which only generates a fake vblank event once every second.
Am 25.07.2016 08:38 schrieb "Michel Dänzer" michel@daenzer.net:
On 13.07.2016 18:49, Rainer Hochecker wrote:
We have been using this for years now and did not observe issues you mentioned. I would be surprised if a child window refreshes in a different rate than the main window
The Xorg driver decides which CRTC to synchronize with based on the window geometry. For a window with no visible geometry, it may choose a different CRTC than for the visible output window. In the case of DRI3, the Xorg Present extension code may even fall back to the fake CRTC in that case, which only generates a fake vblank event once every second.
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
That means that we won't have a solution for X11 with EGL for Intel systems anymore.
On Mon, Jul 25, 2016 at 1:15 PM, Rainer Hochecker fernetmenta@kodi.tv wrote:
Am 25.07.2016 08:38 schrieb "Michel Dänzer" michel@daenzer.net:
On 13.07.2016 18:49, Rainer Hochecker wrote:
We have been using this for years now and did not observe issues you mentioned. I would be surprised if a child window refreshes in a different rate than the main window
The Xorg driver decides which CRTC to synchronize with based on the window geometry. For a window with no visible geometry, it may choose a different CRTC than for the visible output window. In the case of DRI3, the Xorg Present extension code may even fall back to the fake CRTC in that case, which only generates a fake vblank event once every second.
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
That means that we won't have a solution for X11 with EGL for Intel systems anymore.
I didn't know about this, but a proper EGL extension, implemented on X11 exists already:
https://codereview.chromium.org/2867513002/
It's not in the khronos registry, but mesa implements it, and semantics match oml_sync (and wayland present), so we already have the proper extension to implement this without digging around in device files and making a guess about which pipe you might be running on.
Cheers, Daniel
On 05/05/2017 09:35 PM, Daniel Vetter wrote:
On Mon, Jul 25, 2016 at 1:15 PM, Rainer Hochecker fernetmenta@kodi.tv wrote:
Am 25.07.2016 08:38 schrieb "Michel Dänzer" michel@daenzer.net:
On 13.07.2016 18:49, Rainer Hochecker wrote:
We have been using this for years now and did not observe issues you mentioned. I would be surprised if a child window refreshes in a different rate than the main window
The Xorg driver decides which CRTC to synchronize with based on the window geometry. For a window with no visible geometry, it may choose a different CRTC than for the visible output window. In the case of DRI3, the Xorg Present extension code may even fall back to the fake CRTC in that case, which only generates a fake vblank event once every second.
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
That means that we won't have a solution for X11 with EGL for Intel systems anymore.
I didn't know about this, but a proper EGL extension, implemented on X11 exists already:
https://codereview.chromium.org/2867513002/
It's not in the khronos registry, but mesa implements it, and semantics match oml_sync (and wayland present), so we already have the proper extension to implement this without digging around in device files and making a guess about which pipe you might be running on.
Cheers, Daniel
Yep. The weird thing about that extension is that it only implements the query vblank count/timestamp part of GLX_OML_sync_control. Sounds like the least useful bit of all in isolation, although the extension as a whole could be useful, just as on GLX. Also note this comment on that commit referenced by Daniel from just 2 hours ago:
"marcheu 2 hours, 35 minutes ago (2017-05-05 18:52:45 UTC) #10 lgtm
By the way, there is discussion on dropping this extension from mesa. You should let Chad know if you need it in the long run. Chrome OS stopped requiring it when we switched to freon."
Cc'ing Chad Versace on the off-chance he is the mentioned Chad.
Also, the VDPAU api for video playback implements functions for precise timing of video frame presentation. I don't have any practical experience with them, but iirc Mesa's VDPAU video presentation api implements those via DRI3/Present extension, so hooks into drmWaitVblank et al. If Kodi uses VDPAU for playback, it could use those conveniently for timing.
-mario
Yep. The weird thing about that extension is that it only implements the query vblank count/timestamp part of GLX_OML_sync_control. Sounds like the least useful bit of all in isolation, although the extension as a whole could be useful, just as on GLX. Also note this comment on that commit referenced by Daniel from just 2 hours ago:
"marcheu 2 hours, 35 minutes ago (2017-05-05 18:52:45 UTC) #10 lgtm
By the way, there is discussion on dropping this extension from mesa. You should let Chad know if you need it in the long run. Chrome OS stopped requiring it when we switched to freon."
Cc'ing Chad Versace on the off-chance he is the mentioned Chad.
Also, the VDPAU api for video playback implements functions for precise timing of video frame presentation. I don't have any practical experience with them, but iirc Mesa's VDPAU video presentation api implements those via DRI3/Present extension, so hooks into drmWaitVblank et al. If Kodi uses VDPAU for playback, it could use those conveniently for timing.
-mario
Kodi needs interoperability between vpdau and GL, it does not use vdpau's presentation queue. Currently vdpau is bound to GLX and there don't seem to be any activity to change this, it will most likely die with X11.
Kodi will get Wayland support soon, a GSOC project was just acceptend wich I will mentor. We already have support for Mir. That means Kodi is fine if you go ahead with this RFC.
Rainer
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Mario Kleiner -
Michel Dänzer -
Rainer Hochecker