I don't think we want to use the same Gallium context for multiple state trackers and/or the Gallium code in the application, because they will break each other's assumptions about bound constant objects and state.
There may be some synchronization issue. Currently Nouveau multiplexes all the Gallium context on a single hardware FIFO. Other driver can implement and use fence objects. eglBindAPI seems to cause eglCreateContext/eglMakeCurrent to not create on OpenGL context, but rather create and manipulate a context for the other API. Is that correct? Gallium doesn't have a notion of a current context, so it seems it wouldn't fit that well. Resource sharing only requires sharing a pipe_screen, which is part of the point of accessing Gallium via GLX/EGL. It could be accomplished with an additional OpenGL extension providing APIs like glGetGalliumTextureMESA(texid), glGetGalliumBufferMESA(bufid), glGetGalliumRenderbufferTextureMESA(rbid), glGetGalliumFenceMESA(fence) possibly glGetGalliumFramebufferMESA(fboid, pipe_framebuffer_state*).
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
