New issue
Advanced search Search tips

Issue 979 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2015
OS: ----
Priority: Medium
Renderer: ----
Type: Defect

Sign in to add a comment

in-use framebuffer handles are reused after context is re-created (when copying state from previous context)

Reported by, Apr 22 2015

Issue description

What steps will reproduce the problem?
1. generate an FBO
2. create a new context, using the previous context as share_context
3. generate an FBO - the FBO ID will be the same as that above

When creating a new context the GL state of the previous context should be copied completely, including the allocated FBOs.

Context.cpp shows that mResourceManager is being copied, but the FBO handles seem to be managed by the mFramebufferHandleAllocator. I wonder if the other 'Allocator' members should also be copied?

>git rev-parse HEAD

On Windows 8
Project Member

Comment 1 by, Apr 22 2015

Is this a bug? Framebuffers are not shared objects, meaning each context has its own list of separate, unshared framebuffers. See Appendix D of the ES3 spec.

Comment 2 by, Apr 22 2015

I cant speak for the spec but it seems unusual - eglCreateContext is used by some context management libraries (e.g., GLFW) with the expectation that the contexts resources will be shared (this is the only way to switch between video modes)

On reading the specs, I remain confused. The OpenGL ES 2 spec (which it is my understanding is the most relevant?) reads: 

    One way to avoid this undefined behavior is to use GenFramebuffers for all framebuffer object names. Framebuffer objects with names returned by genFramebuffers in one context will never be shared with framebuffer objects whose names were returned by GenFramebuffers in another context

To me this indicates that there is a bug - I am personally using GenFramebuffers in my application and the names are indeed conflicting between contexts.

I wonder though why renderbuffer objects would be explicitly shared and framebuffer objects not? That seems to make the context sharing functionality /almost/ yet not quite useful... 
Project Member

Comment 3 by, Apr 22 2015

Status: WontFix
Hey cechner, can you confirm that GLFW relies on FBOs to be shared?

To help clarify: if the spec says something is undefined (as the GLES2 spec does in Appendix C for FBO sharing) that means ANGLE gets to choose. Since FBOs aren't shared in GLES3, it makes sense to never share them in 2 if we get the choice. So it doesn't seem like there's a bug here -- but if GLFW runs on GLES2 and expects FBOs to be shared it's relying on undefined behaviour, which is a bug. I'm happy to help explain the spec in this aspect.
Project Member

Comment 4 by, Apr 22 2015

Oh yes, about GenFramebuffers - it's a bit hard to visualize without seeing your code. I think what the spec is suggesting is that instead of using BindFramebuffer(###) to create a Framebuffer, use GenFramebuffers, then it's up to you to manage your Context such that you are using the right FBO. I agree the spec is not very helpful here.

Comment 5 by, Apr 23 2015

Hi, thanks for the quick response. I agree that this is probably not a bug, upon reading the spec more closely. It is a shame, as it makes context sharing less useful but the workaround is quite simple (just create separate FBOs for each context)

Regarding code - I didnt post anything because my work is through a wrapper library I wrote. But you can see my workaround here (just deleting all FBOs when context is recreated - I was previously relying on each FBO reloading itself independently but they were stepping on each others toes.  Deleting them all at once fixes this)

Thanks again

Comment 6 by, Apr 23 2015

also regarding GLFW - it does not actually rely on FBOs being shared, I was wrong about that. It is more that the help I could find regarding changing video modes did not mention that FBOs needed to be recreated, so I assumed that they did not need to be

Sign in to add a comment