On Sun, Jan 03, 2010 at 04:14:30PM +0100, Luca Barbieri wrote: > 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. Every call to eglCreateContext will create a new pipe context. You may consider the currently bound API as an additional argument. That is,
eglBindAPI(EGL_xxx_API); eglCreateContext(...); is equivalent to eglCreateContext(..., EGL_xxx_API); When one calls, for example, eglCreateContext(..., EGL_OPENGL_API), EGL will create a pipe context, which is wrapped in a Mesa st context, which is wrapped in an EGL context. eglGetGalliumContext() ignores the Mesa st context and peeks the implementation detail; While making Gallium a client API fits perfectly with the EGL model. When one calls eglCreateContext(..., EGL_GALLIUM_API_MESA) EGL will create a pipe context wrapped in a EGL context. One benefit of this approach is that Mesa st context will not be created. If eglGetGalliumContext() was implemented, it could be still used to get the underlying pipe context. But now that Gallium is a client API, it would be better if the task is left to Gallium itself. That is, ... > 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. ... we can define "Gallium Client API" to something like #include "pipe/p_state.h" /** * Most API entries of Gallium are provided as member functions of the * pipe context. Unlike other client APIs, where all entries assume * an implicit argument (that is, the current context), Gallium has no * such assumption, except for g3dGetContext(). */ struct pipe_context * g3dGetContext(void); Since pipe context has no reference count, a note might be added /** * The returned pipe context may be used even if the context is no * longer current. This is because there is no assumption of a * current context in Gallium. However, one should note that the life * time of the context is not defined by Gallium itself. It depends * on the API used to create the pipe context. */ > 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*). -- Regards, olv ------------------------------------------------------------------------------ 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
