On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu <olva...@gmail.com> wrote: > This patch series adds st_api interface to st/mesa and st/vega, and > switch st/egl and st/glx from st_public interface to the new interface. I've pushed most of the this patch series to gallium-st-api. I'd like to have this topic branch focus on the switch of st/egl and st/glx to use st_api. Further works, such as the switch of st/dri, EGLImage extensions will happen directly in master or some other topic branches, whichever suits better.
The implementations of the new interfaces (st_api, st_framebuffer_iface) are isolated in new files in each state tracker. The isolation makes it easier to locate the changes. But more importantly, unlike the rest of a state tracker, the interfaces might be called from different threads. I used whatever existing mechanisms available to protect those callbacks, but when there is no such mechanism, I ignored the issue mostly. I have one open question so far. With st_api, co state trackers no longer have access to pipe_contexts. The pipe_contexts are usually used to implement * glXCopySubBufferMESA: copy a region of the back buffer to the front * eglCopyBuffers: copy the render buffer of a surface to a pixmap * SwapBuffers and FlushFront in DRI1 The copying is a framebuffer operation and it does not make sense to steal a random API context for the copying. Remember that the co state trackers always own the pipe_textures of a drawable in st_api. One way to solve the problem is to let the co state trackers own pipe_contexts of their own. A co state tracker may create its pipe_context (and probably a blitter context) on demand when glXCopySubBufferMESA or eglCopyBuffers is called and do the copying directly. But as all the 3 cases need to do a pipe_screen::flush_frontbuffer after the copying, a better approach might be to rename and enhance pipe_screen::flush_frontbuffer to support them directly, or a mix of both approaches. -- o...@lunarg.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
