优化视频内存和系统内存之间的传输答案

【问题标题】：Optimizing transfer between video memory and system memory优化视频内存和系统内存之间的传输
【发布时间】：2015-05-29 09:17:30
【问题描述】：

前段时间，我尝试使用 GLSL 在 GPU 上创建重型声音合成器。该合成器能够同时生成超过 256 种以上的非常复杂的声音。在 CPU 上，我做梦也不敢想能得到这样的性能。

（简化解释）为了生成声音，我有一个 NxV 大小的浮点纹理。 N = 样本数，V = 声音数。合成着色器为每个纹素生成值。

然后，第二个着色器会将所有声音混合到一个 16 位有符号整数 1D 纹理（或声卡所需的任何格式）中。这个最终的纹理使用像素缓冲区尽可能快地复制到系统内存，然后将其发送到声卡。

对于声音，我使用超低延迟的 Windows Core Audio。

我编写了一个 MIDI 接口，以便能够在连接到 PC 的 MIDI 键盘上播放，并且在使用延迟仅为 3 毫秒的英特尔 GPU 时它可以完美运行（N = 132 个样本，这比所需的要好得多15-20ms N=600-900 个样本）。但是当使用 NVidia GPU 能够支持更繁重的计算时，延迟会更大（>35ms N=>1500 个样本）。

我知道原因是当使用 Intel GPU 时，渲染是直接在系统内存上完成的，并且复制该纹理非常快，但是当使用 NVidia GPU 时，渲染是在显存中完成并从视频中复制内存到系统内存是一个瓶颈，即使应该传输大约 4KB 的音频数据（这甚至没有接近硬件应该能够传输的 6GB/s）。

有没有办法改善这种情况？例如，是否可以让 NVidia GPU 直接渲染到系统内存（以可接受的速度），或者他们在 OpenCL 中谈论的那些著名的共享内存是什么？ OpenCL 会改善这一点吗？（我没有使用 OpenCL 的经验）

【问题讨论】：

标签： audio memory glsl gpu synthesizer

【解决方案1】：

有时，GPU 写入主内存比 CPU 读取 VRAM 更快。你这样做的方式是使用 PBO，看看here。您必须提示将 PBO 存储在主存储器中。这可能有帮助，也可能没有帮助，具体取决于硬件架构。

OpenCL 并非天生就更快。如果您在 OpenGL 中有一个干净的实现，那么您很可能不会通过 OpenCL 实现来提高速度。但是有些事情你可以在 OpenCL 中做，而用 OpenGL 做不到。

如果您仍然发现带宽是瓶颈，还有一些其他建议：

您是否尽可能避免阻塞？当您在线程中使用 GL 调用读取纹理时，您是否也在另一个线程中处理最后读取的纹理，就像这样。请注意，对 glGetTexImage 的调用是异步的，不会阻塞。只有在您调用 glMapBuffer 之前，您才会阻塞并知道传输已完成。
您是在传输最少的传输次数吗？
存在有损压缩纹理格式，但可能适合您的需求？

【讨论】：

你能告诉我更多关于你说的第一件事的信息：让 GPU 写入主内存吗？我有 2 个带有纹理的帧缓冲区交换到 GPU 渲染声音数据的位置。我使用 PBO 将帧缓冲区数据复制到系统内存。我不明白如何更改 PBO 以使 GPU 存储在系统内存中。我是否需要立即渲染到 PBO 而不是纹理？有这样的例子吗？
至于您的建议： 1. 我想我正在避免所有可能的阻塞：系统的设计使得当请求声音缓冲区时，它应该已经通过 PBO 传输（这似乎成为问题）。 2. 是的，我相信是的。 3. 我明白了，但是数据已经那么小了，我觉得瓶颈更多的是传输的发起，而不是传输本身。这就是为什么我非常渴望了解如何直接渲染到系统内存。
@scippie 请参阅 here 和 here 了解有关设置 PBO 的更多信息
让 GPU 写入主内存只是一个提示，它可能有用也可能没有帮助。请注意，对 glGetTexImage 的调用是异步的，不会阻塞。只有在您调用 glMapBuffer 之前，您才会阻塞并知道传输已完成。
谢谢，我知道所有这些，并且我已经使用了它，除了 READ_STREAM 提示。出于某种原因，我使用了 WRITE_DYNAMIC。我不记得为什么。我稍后会尝试一下。太糟糕了，这只是一个提示，司机可能会选择不这样做。它永远不会给我任何确定性。