On Tue, Jan 19, 2010 at 2:45 AM, Brian Paul <bri...@vmware.com> wrote: >> This is a corner issue, but suppose two contexts are bound to the same >> drawable. One of them wants a depth buffer while the other doesn't (or >> wants a different depth size). There might be a race because one would >> destroy the depth buffer of the other. But this should probably be >> solved by making either of the context incompatible with the drawable. > The GLX spec says something about framebuffer and context compatibility in > terms of RGB vs. CI and some other things. Both GLX contexts and GLX > drawables are generally created with the same GLX visual (or FB config). > But if a context created w/out Z were successfully bound a window without a > Z buffer, the Z buffer would not be magically destroyed. > Note that the issues of framebuffer/context compatibility is probably much > more lax nowadays since we have things like framebuffer objects that may > have any kind of combination of ancillary buffers. I am leaning toward having the state trackers create the buffers they need from the pipe screen, except for color buffers (front/back/left/right) that are potentially visible to the users. egl_g3d is working this way. The requirement by GLX for the buffers to be shareable disallows this. But I think OpenGL state tracker can be made to satisfy both needs. > When we work on code in this area we should also consider the case of using > a rendering context that's bound to no window at all. That could be useful > for FBO rendering or just compiling shaders, etc. Mesa would probably fail > if this were attempted today, but that should get fixed. On the GLX side, glXMakeContextCurrent requires the context and draw/read drawbles to be all non-NULL or all NULL at the same time. The restriction also needs to be lifted, right?
It looks to me that fooMakeCurrent mixes two operations in one function. While working on st_api.h, I want to support it through two state tracker callbacks /* bind the context to the framebuffers */ st_context->bind_framebuffers(st_context, draw, read); /* notify the state tracker the new current context */ st_api->notify_current_context(st_api, st_context); instead of st_api->make_current(st_api, st_context, draw, read); I want that because I think it is clearer. With fooMakeCurrent being overloaded with even more semantics, I feel stronger for that now. (In case you are interested, it is listed as issue 3 in the st_api repo) ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
