On Fri, Mar 12, 2010 at 3:00 AM, Chia-I Wu <olva...@gmail.com> wrote: > 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.
Hmm maybe flush_frontbuffer should be made into a context function, or take a pipe_context. But that would probably require st_framebuffer_iface::flush_front to take a st_context as well. Not that I have anything against that. For eglCopyBuffers the manager probably need a pipe_context for itself. If you don't want to randomly steal one that is currently bound, even then it is not guarantied to be any context created, so as a fallback you will probably always have a context around. Cheers Jakob. ------------------------------------------------------------------------------ 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
