On Mon, Jan 18, 2010 at 1:45 PM, Brian Paul <bri...@vmware.com> wrote: > Chia-I Wu wrote: >> On Fri, Jan 15, 2010 at 08:44:27AM -0700, Brian Paul wrote: >>> Chia-I Wu wrote: >>>> 2010/1/15 Michel Dänzer <mic...@daenzer.net>: >>>> Another question I have is, if depth/stencil should be shareable, how >>>> about other buffers like multisample buffer? (This is a real question >>>> that has >>>> bothered me for a while. I am eager for an answer here.) >>> Yes, I believe the GLX spec indicates that all ancillary buffers >>> associated with a window are to be sharable. >> Thanks. This helps a lot. >> >> 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. > > 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.
I just implemented this for then intel DRI driver. It is indeed very useful and quite straight forward. My take on the MESA_screen_surface + EGL is that we shouldn't try to wrap the KMS API in a GL extension. It's a complicated API that is still evolving. Instead, being able to bind a native GEM/TTM buffer to a GL render buffer along with an extension to make a context current without requiring a surface/drawable is a perfect companion to the KMS API. I'm finishing up a branch with this work now and will post an announcement/description later. cheers, Kristian ------------------------------------------------------------------------------ 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
