On Fri, Mar 12, 2010 at 1:12 PM, Chia-I Wu <olva...@gmail.com> 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've changed st/egl and st/glx to create a pipe_context as needed to copy between pipe_textures. Only pipe_context::surface_copy is used. It seems to be the easiest way to do things right now.
As a result, gallium-st-api passes as many piglit quick tests as the master branch does! > 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. > > This solves the problem with glXCopySubBufferMESA and eglCopyBuffers. What > remain to be done for the DRI1 case is to define the DRI1 displaytarget and > switch st/dri to use it. > > Down to the lowest level, DRI1 displaytarget still faces the problem of > displaying a pipe_texture, given struct dri1_api. In the case > dri1_api::front_srf_locked is supported, it still needs to copy the texture. > > Therefore, a mixed approach seems be the best. With the change to > pipe_screen::flush_frontbuffer, glXCopySubBufferMESA and eglCopyBuffers do not > need a pipe_context. And a pipe_context will be created by st/dri when DRI1 > is > used. This mixed approach requires less work. As DRI1 is phasing out, I > think > it is a sensible approach. > > This is just some ideas. The switch of st/dri can be delayed until > gallium-st-api is merged. But if you are interested, I also have a local > branch that switches st/dri to use st_api, but only the DRI2 part. It is > functioning, but the patch is a little bit dirty.. > > -- > o...@lunarg.com > -- 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
