GL_STATIC_DRAW与GL_DYNAMIC_DRAW与GL_STREAM_DRAW：有关系吗？

在OpenGL中，缓冲对象函数（glBufferData，glBufferSubData和，可能还有其他一些）具有参数usage，该参数在文档中被描述为预期用途的暗示，可能意在帮助实现更好的性能。

用法

指定数据存储的预期使用方式。符号常量必须是GL_STREAM_DRAW，GL_STREAM_READ，GL_STREAM_COPY，GL_STATIC_DRAW，GL_STATIC_READ，GL_STATIC_COPY，GL_DYNAMIC_DRAW，GL_DYNAMIC_READ，或GL_DYNAMIC_COPY。
[...]
用法向GL实现提供了有关如何访问缓冲区对象的数据存储的提示。这使GL实现能够做出更明智的决策，从而可能显着影响缓冲区对象的性能。但是，它并不限制数据存储的实际使用。

维基同样含糊不清：

毕竟，这些只是提示。在创建STATIC缓冲区之后修改它，或者永远不要修改STREAM缓冲区，这是完全合法的OpenGL代码。
[...]
这些问题只有通过仔细分析才能回答。即便如此，答案也仅对来自特定硬件供应商的特定驱动程序版本是准确的。

最后，这个参数有多相关（如果有的话）？驾驶员是否真的考虑到了这一点，如果确实如此，根据您的经验，它在实践中会对性能产生多大影响？您有数据要共享吗？

我已经编写了一个薄的图形API抽象层，打算将其作为现有API中的任何一个实现，并且很想完全忽略此参数并将其从公开的抽象中隐藏起来。

不同的实现会有所不同，但是我研究的驱动程序确实使用了这些驱动程序，主要是用来确定内存布局。这些提示启用的优化比您想要的要小得多，这主要是因为您可以使用给出的任何提示进行限制。例如，如果根本无法写入提示用于读取访问的缓冲区，那么会使缓存失效的成本大大降低，但是这种优化是不可能的。

一些被广泛用于GPU之间基准比较的著名游戏无法正确使用这些提示，因此GPU供应商有动力即使在提示不匹配的情况下也能快速使用所有提示。

在功能上它们是相同的。

驾驶员可以使用它们来区分如何在后台处理缓冲区。例如，将static_draw尽快复制到vram并保留在那里，但是stream_read将始终在RAM中选择日期复制。

这种模糊性是glBufferStorage成为事物的原因。这样，您可以指定要对缓冲区执行的操作（是否将通过BufferSubData更新缓冲区，是否通过映射进行读取或写入，映射的一致性，映射是否可以在整个使用过程中持续存在）超出这些界限是错误的。