2

我想知道是否可以通过任何文件描述符捕获屏幕 vsync 事件并 [select | 民意调查 | epoll]。

通常，如果我是对的， glXSwapBuffers() 不会阻止该过程，因此我可以执行以下操作：

int init() {
    create epollfd;
    add Xconnection number to it;
    add some other fd like socket timer tty etc...
    possibly add a vsync fd like dri/card0 or fb0 or other???
    return epollfd;
}

main() {
    int run = 1;
    int epollfd = init();

    while(run) {
        epoll_wait(epollfd, ...) {

        if(trigedfd = socket) {
            do network computing;
        }

        if(trigedfd = timer) {
            do physics computing;
        }

        if(trigedfd = tty) {
            do electronic communications;
        }

        if(trigedfd = Xconnection number) {
            switch(Xevent) {
                case key event:
                    do key computing;
                case mouse event:
                    do mouse computing;
                case vsync???:
                    do GL computings;
                    glXSwapBuffers();
            }
        }

        if(trigedfd = dri/card0 or fb0 or other???) {
            do GL computings;
            glXSwapBuffers();
        }
    }
}

因此，无论何时发生 vsync 事件，我都可以触发任何事件，并在仅使用 X 绘图功能和可能 GL 进行 vsync 的情况下避免撕裂效应。

libdrm 可以帮助我吗？更普遍的问题是：

那么我必须使用什么 fd 来捕获 vsync 事件以及如何使这个 fd 上发生的事件是 vsync 事件？

4

2 回答 2

2

看起来您可以使用 libdrm API 来查看 vsync 事件。请参阅此博客条目，尤其是此示例代码。代码中的注释解释了它是如何工作的：

/* (...)
 * The DRM_MODE_PAGE_FLIP_EVENT flag tells drmModePageFlip() to send us a
 * page-flip event on the DRM-fd when the page-flip happened. The last argument
 * is a data-pointer that is returned with this event.
 * (...)
 */

您需要设置一个页面翻转事件处理程序，以便在发生 vsync 时收到通知，该drmHandleEvent方法将由您可以在 drm 文件描述符上有活动时调用的方法（来自 libdrm）调用。

但是，将所有这些映射到 X 客户端可能会很困难或不可能。可能您可以自己打开 drm 设备并只监听 vsync 事件（不尝试设置模式等），但这也可能被证明是不可能的。相关代码：

drmEventContext ev;
memset(&ev, 0, sizeof(ev));
ev.version = DRM_EVENT_CONTEXT_VERSION;
ev.page_flip_handler = modeset_page_flip_event;

// When file descriptor input is available:
drmHandleEvent(fd, &ev);
// If above works, "modeset_page_flip_event" will be called on vertical refresh.

问题是页面翻转事件似乎只有在您实际发出页面翻转（缓冲区交换）请求时才会生成。大概是 X 服务器发出了这样的请求，但它甚至不一定标记它想要在 vsync 实际发生时得到通知（即使用DRM_MODE_PAGE_FLIP_EVENT标记）。

打开正确的 dri 设备也很困难（/dev/dri/card0或/dev/dri/card1或...？）

鉴于上述所有问题的难度/不可靠性/一般不可行，最简单的解决方案可能是：

  1. 使用单独的线程来等待使用标准 GL 调用的 vsync。根据OpenGL wiki 上的这个页面，您应该使用它glXSwapIntervalEXT(1)来启用 vsync，然后glXSwapBuffers确保glFinish垂直回溯实际发生。
  2. 然后，通知主线程发生了垂直回溯。您可以通过将数据发送到管道或在 Linux 上使用eventfd.

更新：

您也许可以使用GLX_INTEL_swap_event 扩展：

由 glXSelectEvent 的参数接受并在 glXGetSelectedEvent 的参数中返回：

GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK 0x04000000

在“交换完成”事件的字段中返回：

GLX_EXCHANGE_COMPLETE_INTEL 0x8180
GLX_COPY_COMPLETE_INTEL 0x8181
GLX_FLIP_COMPLETE_INTEL 0x8182

...

客户端可以请求在窗口上接收交换完成 GLX 事件。当接收到事件时，调用者可以通过检查 event_type 字段来确定发生了哪种交换。

这意味着，如果支持扩展，您可以通过常规 X 事件接收交换通知（如果启用 vsync，则对应于垂直回溯），您将在 X 连接文件描述符上看到。

于 2016-04-27T11:43:14.010 回答
2

不幸的是，通过在网上寻找扩展和接口来轮询 vsync [1]，我发现可能可用的最佳（资源最少）方法如下：

  1. 查询 vtrace 速率（对于 60hz 监视器，每 16.666 毫秒）。
  2. nanosleep该延迟的一部分（例如 15 毫秒）取决于查询精度和垂直同步脉冲的预期方差。
  3. clock_gettime如果可以的话，我们剩余的时间配额和（可选）做一些实时计算。通常计算应在第 7 步完成。
  4. 使用下面提到的方法之一忙于等待 vsync。添加pause说明。
  5. 立即clock_gettime确保下一个周期的准确睡眠延迟。
  6. 进行绘图或像素查询。
  7. 进行任何其他计算，使用线程、看门狗或实时计算。
  8. 重复步骤 2。

如果您信任自己的代码，则可以动态增加延迟时间（但过于激进，您会开始丢帧）。如果您真的需要可靠的轮询并且根本无法自旋锁，您可以在另一个线程中完成所有这些操作。nanosleep应该确保内核不会在其生命周期的大部分时间里安排您的线程。

您必须校准延迟，但您可能会注意到它。15ms 非常保守，几乎可以保证工作。我使用的查询方法会产生大约 16.665-16.667 的差异，因此任何低于此的延迟都应该足够了。这完全取决于您对nanosleep实现和线程调度程序的信任程度。如果您的内核支持，请使用实时调度策略（或者不要担心任何这些，采取简单的方法并像其他人一样忙碌等待）。

这是大多数屏幕录像机使用的方法。

查询 Vblank 频率

如果您的驱动程序支持它，您可以反复调用glXGetVideoSyncSGI（从GLX_SGI_video_sync扩展）和时间clock_gettime来查询 vblank 速率（例如 16.666 毫秒）。寻找垂直同步率的替代方法是glXGetSwapIntervalMESA和glXQueryDrawable(dpy, drawable, GLX_SWAP_INTERVAL_EXT, &interval)（分别来自GLX_MESA_swap_control和GLX_EXT_swap_control）。的好处GLX_SGI_video_sync是你只需要一个扩展（见下一节）。

glXGetSyncValuesOMLfrom GLX_OML_sync_controlextension 返回相同的计数器，但可能效率较低，因为它必须获取其他不相关的值。它可能会返回更准确的垂直同步速率。它在我的系统上也不可用，所以我不知道它的便携性如何。

等待垂直同步

您可以在每帧之后设置一个计时器，例如在当前帧开始后约 15 毫秒（clock_nanosleep如果可以的话，使用和非相对时间），然后忙等待其余的时间，直到glXGetVideoSyncSGI计数器改变值。将计时器连接到轮询/事件循环应该是微不足道的。

如果你足够勇敢的话，你也许可以在繁忙的循环中做一些实时计算。

glXWaitForMscOMLfromGLX_OML_sync_control做同样的事情并且可能有一些优化，但它在我的系统上不可用，如果它只是像其他所有东西一样忙于等待，我不会感到惊讶。我也不知道它有多可靠。当然还有其他等待 vsync 的方法（MESA/DRM/KMS），但它们的可移植性甚至不如GLX_SGI_video_sync，而且它们通常是忙等待。

即使没有可用的帧计数器，您也可以假设glXSwapBuffers阻塞并仍然执行类似的操作（请注意，在我知道的所有驱动程序上，用户可以手动关闭阻塞行为。检查并GLX_EXT_swap_control尝试覆盖此行为）。不过，此时glXSwapBuffers在另一个线程中循环调用可能会更好。

如果一切都失败了，你可以忙着等待clock_gettime。nanosleep曾经这样做，但现在你必须自己做。如果您使用此方法，您可能应该对众所周知的 vsync 值进行硬编码，而不是依赖查询（睡眠延迟的任何变化都可能导致丢帧，因为硬件的异步特性，所以说 vsync 无论如何都有自然变化，所以没有驱动程序支持的可靠 vsync 可能是不可能的）。

“compton”开源合成器管理器提到了以下等待方法vsync：

  • DRM_IOCTL_WAIT_VBLANK

Linux 特定的。等待非常可靠，也不需要OpenGL。正确挂起线程而不是忙于等待。不幸的是，_DRM_VBLANK_SIGNAL没有实现并且_DRM_VBLANK_EVENT被破坏了，所以阻塞等待仍然是唯一有效的用例。DRM 实际上确实为手动交换缓冲区的应用程序提供了准确的 vsync 脉冲，但这很难被调用lightweight。此外，如果您无论如何都在交换缓冲区，您不妨只使用glXSwapBuffers. 如果您需要高性能并且不关心便携性，建议您使用。

  • SGI_video_sync

跨平台。几乎普遍可用。这是我推荐的。

  • OML_sync_control

有的话推荐。

  • EXT_swap_control
  • SGI_swap_control
  • MESA_swap_control

我不会推荐这个。这就是glXSwapBuffers方法。大多数驱动程序都支持这一点，但如果驱动程序设置发生变化，它也是资源密集型的并且容易中断。大多数这些实现自旋锁。

结论

不幸的是，似乎短期内不会有一种资源友好的方式来轮询 vsync。视频驱动程序显然必须跟踪 vsync 以知道何时发送下一帧，因此没有技术原因可以在任何地方都没有简单的接口来轮询 vsync 脉冲，但不幸的是，来自 linux、nvidia 和 khronos 的共识似乎是“没有人需要这个”。

通常 vtrace 脉冲对于像素查询非常重要（案例点：实际上每个合成器管理器都有关于 vsync 的错误报告或邮件列表线程），但它也用于实时计算。

[1] vsync aka vtrace aka 缓冲区交换 aka 帧计数器增量 aka 帧往返

于 2020-05-09T10:06:08.007 回答