<分区>
我将 glTexSubImage2D 用于使用 openGL 的更新窗口。
我看到这个函数需要很长时间才能返回，而且它还占用 4% 的 CPU。
这是我使用的代码:
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, (*i)->getTextureID());
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, (*i)->getWidth(), (*i)->getHeightView(),
GL_BGRA, GL_UNSIGNED_BYTE,(*i)->getBuffer());
有人知道更好的实现吗？性能更好但占用 CPU 更少的东西？
现在这让我的程序变慢了。
最佳答案
有些事情您可以做，但您能从中受益多少取决于具体情况。
首先，确保您的像素上传格式符合驱动程序的需要。你似乎已经用 GL_BGRA, GL_UNSIGNED_BYTE 处理了这个问题，这可能是驱动程序对 GL_RGBA8 图像格式的首选格式。
但是，如果您碰巧可以访问 OpenGL 4.3 或实现 ARB_internalformat_query2 的驱动程序，您实际上可以在运行时检测到首选上传格式是什么。 Like this :
GLint pixelFormat, pixelType;
glGetInternalFormativ(GL_TEXTURE_2D, GL_RGBA8, GL_TEXTURE_IMAGE_FORMAT, 1, &pixelFormat);
glGetInternalFormativ(GL_TEXTURE_2D, GL_RGBA8, GL_TEXTURE_IMAGE_TYPE, 1, &pixelType);
当然，这意味着您将需要能够修改数据生成方法以生成上述格式/类型对的数据。
一旦你采取措施安抚司机，你的下一个可能性是使用 buffer objects to store your pixel transfer data .这可能对整体性能没有帮助，但可以减轻 CPU 负担。
但是，为了充分利用这一点，您需要能够通过 mapping it 将像素数据“直接”生成到缓冲区对象的内存中。 .如果你能做到这一点，那么你可能会收回一些上传的 CPU 成本。否则，可能不值得。
如果你这样做，你应该使用适当的 buffer object streaming techniques .
对纹理进行双重缓冲也可能有所帮助。也就是说，当您从一个纹理对象渲染时，您正在上传到另一个纹理对象。这将防止等待先前渲染完成的 GPU 停顿。这有多大帮助实际上取决于您的渲染方式。
在不了解您的应用程序的具体情况的情况下，没有太多可说的。
关于c++ - GlTexSubImage2D 慢并且使用 4% 的 CPU，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13112318/