OpenGL“内存不足”在 glReadPixels() 上
在内存不足的情况下，我在 glReadPixels() 上遇到 OpenGL 的“内存不足”错误。我正在为一个程序编写一个插件，该程序具有针对此类情况的强大堆机制，但我不知道 OpenGL 是否或如何使用它来进行应用程序内存管理。我通过这个关于 Mac OS [非 X] 下类似问题的 [尽管已过时] 线程，注意到了这种可能性的概念：http://lists.apple.com/archives/Mac-opengl/2001/Sep/msg00042.html
我使用的是 Windows XP，并且在多张 NVidia 卡上都看到过它。我也对我可能能够转发给用户的任何解决方法感兴趣（该线程提到“增加虚拟内存”）。
谢谢，肖恩
I am running into an "out of memory" error from OpenGL on glReadPixels() under low-memory conditions. I am writing a plug-in to a program that has a robust heap mechanism for such situations, but I have no idea whether or how OpenGL could be made to use it for application memory management. The notion that this is even possible came to my attention through this [albeit dated] thread on a similar issue under Mac OS [not X]: http://lists.apple.com/archives/Mac-opengl/2001/Sep/msg00042.html
I am using Windows XP, and have seen it on multiple NVidia cards. I am also interested in any work-arounds I might be able to relay to users (the thread mentions "increasing virtual memory").
Thanks, Sean
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我很确定内存不足错误不是从 glReadPixels（事实上glReadPixels本身并不分配内存）。
该错误可能是由分配缓冲区对象或纹理的其他例程引发的。一旦检测到内存不足错误，您应该释放所有非强制缓冲区对象（纹理、纹理 mipmap、很少使用的缓冲区对象），以便分配一个新的缓冲区对象来保存 glReadPixels 返回的数据。
I'm quite sure that the out-of-memory error is not raised from glReadPixels (infact glReadPixels doesn't allocate memory itself).
The error is probably raised by other routines allocating buffer objects or textures. Once you detect the out-of-memory error, you should release all non-mandatory buffer objects (textures, texture mipmaps, rarely used buffer objects) is order to allocate a new buffer object holding the glReadPixels returned data.
如果没有更多细节，很难说。最终，OpenGL 在需要分配时将与本机操作系统对话。因此，如果没有别的办法，您始终可以替换（或挂钩）进程的默认 CRT/堆分配器，并让它从插件主机中的“更强大”堆管理器中获取块。
Without more specifics, hard to say. Ultimately OpenGL is going to talk to the native OS when it needs to allocate. So if nothing else, you can always replace (or hook) the default CRT/heap allocator for your process, and have it fetch blocks from the "more robust" heap manager in the plugin host.