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
Mesa3d-dev mailing list

Reply via email to