c++ - OpenGL大3D纹理(> 2GB)非常慢
问题描述
我的显卡是GTX 1080 ti。我想使用 OpenGL 3D 纹理。像素(体素)格式为 GL_R32F。当我初始化纹理并使用纹理进行渲染时,OpenGL 没有报告任何错误。
当 3D 纹理很小 (512x512x512) 时,我的程序运行速度很快 (~500FPS)。
但是,如果我将大小增加到 1024x1024x1024 (4GB),FPS 会急剧下降到不到 1FPS。当我监控 GPU 内存使用情况时,GPU 内存不超过 3GB,即使纹理大小为 4GB,我总共有 11G。
如果我将像素格式更改为 GL_R16F,它会再次工作,FPS 回到 500FPS,GPU 内存消耗约为 6.2GB。
我的假设是 4GB 3D 纹理实际上并不在 GPU 上,而是在 CPU 内存上。在每一帧中,驱动程序一次又一次地将这些数据从 CPU 内存传递到 GPU 内存。结果,它会降低性能。
我的第一个问题是我的假设是否正确?如果是,为什么即使我有足够的 GPU 内存也会发生这种情况?如何强制任何 OpenGL 数据驻留在 GPU 内存上?
解决方案
我的第一个问题是我的假设是否正确?
至少,这不是不合理的。
如果是,为什么即使我有足够的 GPU 内存也会发生这种情况?
这是由您的 OpenGL 实现来决定的。请注意,这也可能是一些驱动程序错误。这也可能是一些内部限制。
如何强制任何 OpenGL 数据驻留在 GPU 内存上?
你不能。OpenGL 没有视频 RAM 或系统 RAM 甚至 GPU 的概念。您指定缓冲区和纹理以及其他对象并进行绘制调用,将其映射到实际硬件是 GL 实现的工作。但是,没有任何性能保证 - 当您执行某些操作时,您可能会遇到缓慢的路径甚至回退到软件渲染(后者在最近确实不常见,但从概念上讲,这是很有可能的)。
如果您想控制数据的放置位置、实际传输的时间等,您必须使用更底层的 API,例如 Vulkan。
推荐阅读
- html - nth-of-type 选择器未按预期工作
- c - 一个带有意外输出的简单 C 程序
- python - 在python中使用str返回字典
- django - 如何将 Django 的模板标签与 Vuetify 的输入值一起使用?
- django - 在 Django 中迁移到 PostgreSQL - 类型字符变化的错误值太长(2)
- java - 我对 netty 框架中 ChannelOutboundHandle 的“读取”方法感到困惑
- javascript - 在 ReactJS 中,将一次性运行的东西放在哪里?
- javascript - 没有括号的函数返回一个奇怪的输出
- c# - unity 2018.2 文字颜色渐变
- javascript - 有人可以解释这个循环中的每个变量、运算符、参数等的工作原理吗?