我需要流式传输纹理（本质上是相机供稿）。
使用对象流，似乎会出现以下情况：
新对象的数据存储区是否比旧对象的数据存储区更大，更小或相同？
正在更新子集或整个纹理？
我们是在流缓冲对象还是纹理对象（有什么区别吗？）
以下是我遇到的以下方法：
分配对象数据存储（用于缓冲区的BufferData或用于纹理的TexImage2D），然后分配每个帧，使用BufferSubData或TexSubImage2D更新数据子集
在上次使用该对象的调用（例如绘制）之后，使对象无效/无效：
空值化：glTexSubImage2D（...，NULL），glBufferSubData（...，NULL）
无效：glBufferInvalidate（），glMapBufferRange与GL_MAP_INVALIDATE_BUFFER_BIT，glDeleteTextures？
使用新数据简单地重新调用BufferData或TexImage2D
手动实现对象多缓冲/缓冲ping-ponging。
最直接的问题是，整个纹理被相同大小的新纹理替换。我该如何实施？ （1）会隐式同步吗？ （2）是否避免同步？ （3）是否将同步对象或为对象分配新的数据存储，以便可以在不等待使用旧对象状态完成的所有绘图完成的情况下上传更新信息？相信来自Red Book V4.3的这段话：
也可以使用以下命令在缓冲区对象之间复制数据
glCopyBufferSubData（）函数。而不是组装数据块
在使用glBufferSubData（）的一个大型缓冲区对象中，可以
使用glBufferData（）将数据上传到单独的缓冲区中，然后
从这些缓冲区复制到更大的缓冲区，使用
glCopyBufferSubData（）。根据OpenGL的实现，它可能
能够重叠这些副本，因为每次您致电
缓冲区对象上的glBufferData（），它将使任何内容无效
可能曾经去过那里。因此，OpenGL有时可以
为您的数据分配一个全新的数据存储，即使是副本
先前商店的操作尚未完成。然后它将
稍后释放旧存储。
但是，如果是这样，为什么需要（2）[nullify / invalidates]？
另外，请牢记以下问题，同时讨论以上方法以及其他方法及其在各种情况下的有效性：
是否发生与对象的隐式同步（即，将更新与OpenGL的使用同步）
内存使用情况
速度
我已经读过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_BIT的glMapBufferRange。这样，您就可以在GL使用它们的同时保留所有缓冲区的映射-因此，您可以避免一次又一次地将缓冲区映射到地址空间的开销。然后，您将根本没有隐式同步-但是您必须手动同步操作。 OpenGL的同步对象（请参见GL_ARB_sync）可能会帮助您解决问题，但是同步的主要负担在于应用程序逻辑本身。将视频流传输到GL时，只需避免立即重新使用作为glTexSubImage()调用源的缓冲区，并尝试尽可能长时间地延迟其重新使用。当然，您还需要将吞吐量与延迟进行权衡。如果需要最小化延迟，则可能需要稍微调整此逻辑。
比较“内存使用”的方法确实很困难。这里有很多实现特定的细节需要考虑。 GL实现可能会保留一些旧的缓冲存储器一段时间，以完全满足相同大小的重新创建请求。此外，GL实现可能会随时制作任何数据的卷影副本。原则上，始终不孤立并重新创建存储的方法原则上公开了对正在使用的内存的更多控制。
“速度”本身也不是一个非常有用的指标。根据应用程序的要求，您基本上必须在此处平衡吞吐量和延迟。
关于opengl - OpenGL纹理和对象流，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24559905/