Pro*_*gun 2 opengl streaming buffer textures
我需要流式处理纹理（本质上是摄影机提要）。
使用对象流，似乎会出现以下情况：
以下是我遇到的以下方法：
分配对象数据存储（用于缓冲区的BufferData或用于纹理的TexImage2D），然后分配每个帧，使用BufferSubData或TexSubImage2D更新数据子集
在使用该对象的最后一次调用（例如绘制）之后，使对象无效/无效：
使用新数据简单地重新调用BufferData或TexImage2D
手动实现对象多缓冲/缓冲ping-ponging。
最直接的问题是，整个纹理被相同大小的新纹理替换。我该如何实施？（1）是否会隐式同步？（2）是否避免同步？（3）是否将同步对象或将为该对象分配新的数据存储，以便可以在不等待使用旧对象状态完成的所有绘图完成的情况下将更新上传到该对象？相信来自Red Book V4.3的这段话是这样的：
也可以使用glCopyBufferSubData（）函数在缓冲区对象之间复制数据。不必使用glBufferSubData（）在一个大的缓冲区对象中组装数据块，而是可以使用glBufferData（）将数据上传到单独的缓冲区中，然后使用glCopyBufferSubData（）将这些数据复制到较大的缓冲区中。根据OpenGL的实现，它可能能够重叠这些副本，因为每次您对缓冲区对象调用glBufferData（）时，它会使之前可能存在的任何内容失效。因此，即使从前一个存储进行的复制操作尚未完成，OpenGL有时也可以为您的数据分配一个新的数据存储。然后，它将在以后的机会中释放旧存储。
但是如果是这样，为什么需要（2）[无效/无效]？
另外，请牢记以下问题，同时讨论上述方法以及其他方法，以及它们在各种情况下的有效性：
我已经阅读了http://www.opengl.org/wiki/Buffer_Object_Streaming，但是它没有提供明确的信息。
让我尝试至少回答您提出的几个问题。
您所讨论的方案可能会对不同方法的性能产生重大影响，尤其是在考虑有关缓冲区动态大小的第一点时。在您的视频流场景中，大小几乎不会改变，因此可能会对您使用的数据结构进行更昂贵的“重新配置”。如果大小每帧或每几帧改变一次，通常是不可行的。但是，如果可以实施合理的最大大小限制，那么仅使用具有最大大小的缓冲区/纹理可能是一个不错的策略。无论是使用缓冲区还是使用纹理，都不必使用所有空间（尽管在使用纹理时，如包裹模式，存在一些较小的问题）。
3.我们是否在流缓冲对象或纹理对象（有什么区别？）
好吧，有效地向GL传输图像数据或从GL传输图像数据的唯一方法是使用像素缓冲区对象（PBO）。因此，无论顶点数据，图像数据还是任何要传输的数据，您始终都必须首先处理缓冲区对象。缓冲区只是glTex*Image()纹理情况下某些调用的源，当然，您需要一个纹理对象。
让我们来看一下您的方法：
在方法（1）中，使用更新命令的“ Sub”变体。在这种情况下，现有对象的（部分或全部）存储将被更新。如果仍在使用旧数据，则可能触发隐式同步。GL基本上只有两个选择：根据数据完成所有操作（可能），或者对新数据进行中间复制并让客户端继续。从性能的角度来看，这两个选项均不好。
在方法（2）中，您有一些误解。更新命令的“ Sub”变体将永远不会使您的缓冲区无效/孤立。“ non-sub” glBufferData()将为对象创建一个全新的存储，并将其NULL用作数据指针将使该存储未初始化。在内部，GL实现可能会重新使用一些用于较早的缓冲区存储的内存。因此，如果您采用这种方案，那么如果您始终使用相同的缓冲区大小，则有可能会最终使用相同内存区域的环形缓冲区。
您提到的其他无效方法还可以使缓冲区的某些部分无效，也可以对发生的事情进行更细粒度的控制。
方法（3）与（2）基本相同glBufferData()，只是在此阶段直接指定新数据。
方法（4）是我实际上建议的方法，因为它使应用程序可以最大程度地控制正在发生的事情，而不必依赖GL实现的特定内部工作。
在不考虑同步的情况下，即使要更改整个数据存储，而不仅仅是某些部分，更新命令的“ sub”变体也更加有效。这是因为命令的“ non-sub”变体基本上会重新创建存储并为此带来一些开销。通过手动管理环形缓冲区，您可以避免任何上述开销，并且您不必依靠GL来变得聪明，只需使用更新功能的“ sub”变体即可。同时，您可以通过仅更新GL不再使用的缓冲区来避免隐式同步。该方案也可以很好地扩展到多线程方案中。您可以有一个（或几个）带有独立（但共享）GL上下文的额外线程来为您填充缓冲区，并在更新完成后立即将缓冲区处理传递给绘制线程。您也可以仅在绘制线程中映射缓冲区，然后由工作线程填充（完全不需要其他GL上下文）。
OpenGL 4.4引入了GL_ARB_buffer_storage并附带了GL_MAP_PERSISTEN_BITfor glMapBufferRange。这将允许您在GL使用它们的同时保留所有缓冲区的映射-因此，您可以避免将缓冲区一次又一次地映射到地址空间的开销。然后，您将根本没有隐式同步-但是您必须手动同步操作。OpenGL的同步对象（请参阅GL_ARB_sync）可能会帮助您解决问题，但是同步的主要负担在于应用程序逻辑本身。将视频流传输到GL时，只需避免重新使用缓冲区（缓冲区是缓冲区的源）glTexSubImage()立即致电，并尝试尽可能长时间地延迟其重复使用。当然，您还需要将吞吐量与延迟进行权衡。如果需要最小化延迟，则可能需要稍微调整此逻辑。
比较“内存使用”的方法确实很困难。这里有很多实现特定的细节需要考虑。GL实现可能会保留一些旧的缓冲存储器一段时间，以完成相同大小的重新创建请求。此外，GL实现可能会随时制作任何数据的卷影副本。原则上，始终不孤立并重新创建存储的方法原则上公开了对正在使用的内存的更多控制。
“速度”本身也不是一个非常有用的指标。根据应用程序的要求，您基本上必须在此处平衡吞吐量和延迟。