本文介绍了OpenGL驱动监视器说纹理正在迅速增加。如何找到泄漏?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当我运行我的应用程序时,OpenGL驱动监视器表示纹理计数正在迅速增加 - 在30秒内纹理计数增加了大约45,000个。



但我没有'能够找到泄漏。我已经安装了每一个 glGen *()调用以打印出它返回的每个GL对象名称 - 但它们都小于50,所以显然由 glGen *()不会被泄露。

这是一个庞大而复杂的应用程序,它将多个着色器渲染为多个FBO共享上下文在单独的线程上,所以把它简化为一个简单的测试用例是不现实的。



glGen *() code>来电,我应该检查以确定是什么泄漏?



解决方案

有趣的是,那些 glGen *(... )函数。他们所做的只是为特定类型的对象返回第一个未使用的名称并保留该名称,以便后续调用 glGen *(...)时也不会发出名称。



在首次绑定名称时,在OpenGL中创建的纹理对象(以及所有对象,实际上)实际上是。也就是说, glBindTexture(GL_TEXTURE_2D,1)是用名称 1 创建纹理的实际函数。这里有趣的是,在许多实现中(OpenGL 2.1或更旧版本),即使没有通过调用 glGenTextures(...) glBindTexture(...)仍然会为该名称创建纹理(假设尚不存在)。



底线是 glGenTextures(...)不是创建纹理的东西,它只会给你第一个未使用的纹理名称认定。我会专注于追踪所有对 glBindTexture(...)的调用,而不是传递未初始化的数据作为名称。



更新:



正如datenwolf指出的那样,如果您使用的是3.2+核心上下文,则此行为不适用(名称必须与从OpenGL 3.0开始匹配 glGen *(...)调用)。但是,OS X默认为您提供2.1实现。


When I run my app, OpenGL Driver Monitor says the Textures count is rapidly increasing — within 30 seconds the Textures count increases by about 45,000.

But I haven't been able to find the leak. I've instrumented every glGen*() call to print out every GL object name it returns — but they're all less than 50, so apparently GL objects created by glGen*() aren't being leaked.

It's a large, complex app that renders multiple shaders to multiple FBOs on shared contexts on separate threads, so reducing this to a simple test case isn't practical.

What else, besides glGen*() calls, should I check in order to identify what is leaking?

解决方案

Funny thing, those glGen* (...) functions. All they do is return the first unused name for a particular type of object and reserve the name so that a subsequent call to glGen* (...) does not also give out the name.

Texture objects (and all objects, really) are actually created in OpenGL the first time you bind a name. That is to say, glBindTexture (GL_TEXTURE_2D, 1) is the actual function that creates a texture with the name 1. The interesting thing here is that in many implementations (OpenGL 2.1 or older) you are free to use any random number you want for the name even if it was not acquired through a call to glGenTextures (...) and glBindTexture (...) will still create a texture for that name (provided one does not already exist).

The bottom line is that glGenTextures (...) is not what creates a texture, it only gives you the first unused texture name it finds. I would focus on tracking down all calls to glBindTexture (...) instead, it is likely you are passing uninitialized data as the name.

UPDATE:

As datenwolf points out, if you are using a 3.2+ core context then this behavior does not apply (names must be generated with a matching glGen* (...) call starting with OpenGL 3.0). However, OS X gives you a 2.1 implementation by default.

这篇关于OpenGL驱动监视器说纹理正在迅速增加。如何找到泄漏?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-29 15:57