On Fri, Mar 12, 2010 at 10:08 PM, José Fonseca <jfons...@vmware.com> wrote: > 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). On X11 with software rasterizer, flush_frontbuffer (I use flush_frontbuffer in this mail, but it also applies to display_texture) is implemented through X(Shm)PutImage. When DRI2 is used, it should be implemented through DRI2CopyRegion. The required parameters for calling X(Shm)PutImage or DRI2CopyRegion are provided by screen-specific winsys_drawable_handle. The callback should generally be implemented with window system APIs.
But, there is no efficient way to implement the callback without a pipe_context when DRI1 is used. DRI1 needs to copy the textures (fake front or back) to the real front buffer. Passing pipe_context as a member of winsys_drawable_handle seems to solve the problem, but I am not sure if it is considered a fix or a hack though. flush_frontbuffer is only implemented on software pipe drivers. What DRI1 faces might exist on other window systems (Windows?). It seems the callback cannot be generally implemented without a pipe_context. It should be either move the callback to pipe_context, or keep it in pipe_screen and pass a pipe_context as a member of winsys_drawable_handle for window systems that need it. I am leaning toward the latter right now. > Furthermore, now it is very easy for any state tracker entity to create > a dummy context for if needed, via pipe_screen::context_create(). -- 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
