On 05/05/2017 09:35 PM, Daniel Vetter wrote:
On Mon, Jul 25, 2016 at 1:15 PM, Rainer Hochecker <fernetme...@kodi.tv> wrote:
Am 25.07.2016 08:38 schrieb "Michel Dänzer" <mic...@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to