做工作而不是等待 glMapBuffer
我正在使用 OpenGL 进行一些 GPGPU 处理。所以我有不同的线程为 OpenGL 处理线程提供工作。
在每个“工作项”之后，我需要调用 glReadPixels 和 glMapBuffer 以便将数据从 PBO 传输回主机。然而，这样做的问题是 glMapBuffer 会阻塞线程，并且在 DMA 传输完成之前无法完成任何有用的工作，即使 GPU 处于空闲状态也是如此。解决这个问题的通常方法是创建一个时间深度为最长 DMA 传输的管道。但是，由于我正在开发低延迟系统，因此这并不是最理想的。
有没有办法在单独的线程上等待 glMapBuffer 或者可能获得一些有关 DMA 传输何时完成的通知，以尽可能减少延迟？
I'm using OpenGL for some GPGPU processing. So I have different threads giving work to a OpenGL processing thread.
After each "work-item" I need to call glReadPixels and glMapBuffer in order to transfer back data to the host from the PBO. The problem with this however is that glMapBuffer blocks the thread and no useful work can be done until the DMA transfer finished, even though the GPU is idle. The usual way to solve this is to create a pipeline with a time depth of the longest DMA transfer. However, as I'm working on a low latency system this is suboptimal.
Is there a way to maybe wait for glMapBuffer on a separate thread or maybe get some notification as to when the DMA transfer has finished in order to reduce the latency as much as possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除了 glMapBuffer 阻塞之外，是否在其他线程中进行了一些额外的工作？您可以拥有多个 OpenGL 上下文，每个上下文都在其自己的线程中活动；如果它们配置为共享对象，则它们可以同时操作。
然而，DMA 实际上意味着 GPU 的工作，至少它的带宽被完全消耗，因此您最终可能会获得更糟糕的性能。
Do some additional work in other threads than the one glMapBuffer blocks in? You can have multiple OpenGL contexts, each active in its own thread; if they're configured to share objects they can operate simultanously.
However a DMA actually means work for the GPU, at least the bandwidth to it is fully consumed and so you might end up with even worse performance.