我目前正在 OpenGL 4.3 中使用 UBO 进行渲染,以将所有常量数据存储在 GPU 上。 (诸如材料描述、矩阵等内容)。
它可以工作,但是 UBO 的小尺寸(我的实现为 64kB)迫使我多次切换缓冲区,减慢渲染速度,我正在寻找类似的方法来存储几 MB。
经过一番研究后,我发现 SSBO 确实允许这样做,但也有不需要的“功能”:它们可以从着色器写入,并且读取速度可能较慢。
有没有比 SSBO 更好的解决方案来向着色器提供大块数据?我觉得我错过了一些东西,为什么 UBO 应该限制在几 kB,而存在更灵活的解决方案能够处理更多数据?如果着色器存储缓冲区是我正在寻找的,有没有办法确保它们不被着色器修改?
UBOs and SSBOs fundamentally represent two different pieces of hardware (usually)1.
着色器按组执行,以便每个着色器都以锁步执行。每组单独的着色器调用都可以访问一个内存块。 UBO 所代表的就是这种记忆。它相对较小(大约为千字节),但访问速度相当快。执行渲染操作时,UBO 中的数据会复制到该着色器本地内存中。
SSBO 代表全局内存。它们基本上是指针。这就是为什么它们通常没有存储限制(最低 GL 要求是 16Mega字节,大多数实现返回一个与 GPU 内存大小相同的数字)。
它们的访问速度较慢,但这种性能是因为它们存在的位置和访问方式,而不是因为它们可能不是恒定的。全局内存是全局GPU内存而不是本地常量内存。
如果着色器需要访问的数据超出其着色器本地内存的容量,则需要使用全局内存。即使您有办法声明 SSBO 为“常量”,也无法解决此问题。
1: There is hardware that exists (GCN-based AMD hardware) which doesn't have dedicated UBO storage. This hardware implements UBOs as just a read-only SSBO, so all UBO accesses are global memory accesses. This hardware essentially relies on having large caches to make up for the performance difference, and the patterns of use for UBOs tend to make this viable. But there's still lots of hardware that has dedicated room for UBO storage, so if your use can fit within those limits, you should use them.
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)