https://bugs.freedesktop.org/show_bug.cgi?id=38312
--- Comment #17 from Brian Paul <brian.e.p...@gmail.com> 2011-06-15 07:02:31 PDT --- (In reply to comment #15) > (In reply to comment #14) > > Between the call to glBindFramebuffer() and > > glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()? > > As far as I can see, no, we don't call glXMakeCurrent between these two > points. OK. > > That > > would change the context's framebuffer binding. We might have that wrong, > > actually... > > Why would glXMakeCurrent change GL state? glXMakeCurrent creates a binding between a rendering context and a surface for drawing. The surface (an X Window or GLXPixmaps) is internally represented by an FBO. Window system FBOs like that and user-created FBOs are pretty much the same with only minor differences in how they're handled. In any case, the context has "current FBO" pointers that are set in glXMakeCurrent(). That's a potential state change. The GL_ARB/EXT_framebuffer_object extensions say that calling glXMakeCurrent() should not change the current read/draw FBO bindings if the context is currently pointing at user-created FBOs. I needed to check Mesa to be sure that we weren't inadvertently binding the X window FBO at in this situation. It looks like we're doing the right thing. I just wrote a new piglit test to verify this fact. Anyway, I don't think this is the issue. Perhaps you could sprinkle more glGetIntegerv(GL_FRAMEBUFFER_BINDING, &x) calls between the glBindFramebuffer() call and the failure point. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
