On Thu, 2010-03-11 at 21:12 -0800, Chia-I Wu wrote: > On Fri, Mar 12, 2010 at 12:20 PM, Jakob Bornecrantz > <wallbra...@gmail.com> wrote: > > 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. > I am thinking change pipe_screen::flush_frontbuffer to > > void > pipe_screen::display_texture(struct pipe_screen *, > struct pipe_texture *, > void *winsys_drawable_handle, > unsigned x, unsigned y, > unsigned width, unsigned height); > > The pipe_texture must be created with DISPLAY_TARGET or SCANOUT. The type of > the opaque drawable handle is pipe_screen specific and is known to the co > state > tracker, or whoever, created the pipe_screen.
I'd support this. This is pretty much what I'd need for WGL too. Regarding being pipe_screen vs pipe_context I don't have a strong opinion about this, but I believe making it a context operation is adequate. Presents are translated either to a series of blits or a fullscreen flip. Certain hardware deos not have dedicate blit engines, so having a context for doing the blits via 3d is very handy. On Windows XP presents don't require context. On Vista and later presents already require a rendering context (I typically use the last one that rendered to a surface). Furthermore, now it is very easy for any state tracker entity to create a dummy context for if needed, via pipe_screen::context_create(). Jose ------------------------------------------------------------------------------ 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
