Cur*_*Guo 4 opengl textures shared
我遇到了使用共享上下文的问题:
我有两个线程,每个都有一个上下文,比如Thr1(thread1)和Ctx1(Context1)以及Thr2和Ctx2.Ctx2与Ctx1共享创建.
然后,在Thr2中,我使用Ctx2创建一些纹理作为当前上下文,并进行一些渲染.之后,我销毁Ctx2并完成Thr2.
现在问题出现了:在我销毁Ctx2之后,在Ctx2下创建的纹理没有被释放(其中一些,不是全部).我使用gDebugger来配置我的程序,看到这些纹理没有被释放,并列在Ctx1下.
当我重复创建Thr2/Ctx2并创建纹理并破坏Thr2/Ctx2时,纹理变得越来越多,以及内存.
我尝试过的:
在销毁Ctx2之前删除Thr2中的纹理;
在Thr2中使Ctx1成为当前并尝试删除纹理,在Ctx2被破坏之前;
这听起来像预期的行为.
为了解释具有多个上下文的对象的生命周期,我将使用单词"pool"来描述纹理的集合.我不认为这个概念有通用的术语,所以这和任何东西一样好.
虽然您通常可以将纹理描绘为由上下文拥有,但它们实际上归池所有.只要你只有一个背景,这就是学术上的差异.上下文拥有池,池拥有在上下文中创建的所有纹理.当上下文被破坏时,池会随之消失,从而破坏池中的所有纹理.
现在,通过两个共享上下文,事情变得更有趣.您仍然有一个池,两个上下文共享所有权.在两个上下文中的任何一个中创建纹理时,纹理由共享池拥有.删除上下文后,它将放弃其对池的共享所有权.只要至少有一个上下文存活,池(包括池中的所有纹理)就会保持不变.
在您的方案中,上下文2创建纹理.此纹理将添加到上下文1和上下文2共享的池中.然后删除上下文2.创建的纹理将保留在池中.池本身仍然存在,因为上下文1(仍然存在)共享池的所有权.这意味着纹理也保持活力.上下文2创建纹理是无关紧要的,因为纹理由池拥有,而不是由上下文2拥有.
因此,如果您确实要删除纹理,则必须进行glDeleteTexture()调用.如果您在上下文1或上下文2中进行此调用,则无关紧要.
删除共享纹理时存在一些微妙的方面,例如与作为FBO附件的纹理相关,或者在另一个上下文中绑定时在一个上下文中删除纹理.但由于这不是这个问题的核心,而且有点复杂,我将参考详细规范(参见OpenGL 3.3规范第337页的D.1.2节).