On 11 mar 2010, at 04.15, Chia-I Wu wrote: > Hi all, > > 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. > > Feature-wise, st_api provides a more robust multiple client APIs > (OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of > various EGLImage extensions. As st_api interface can coexist with > st_public interface, co state trackers should work as before unless > they > are switched to use st_api. > > The original plan to merge the work to master after the interface is > implemented by st/mesa and st/vega, and st/egl is converted to use it. > Further development and conversions of st/glx and st/dri will happen > in > master. While this is still the plan, the recent merge of > gallium-sw-api-2 motivates me to submit this WIP patch series for > public > review. I will cover only pipe_screen::update_buffer, > pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front > here as the other parts were discussed a while ago. But any > feedback to > the design is appreciated. > > To summarize, there is *no* change to pipe_screen::update_buffer and > pipe_screen::flush_frontbuffer. This guarantees the non-Khronos state > trackers are not affected, and the st_public path of st/mesa and st/ > vega > still work. But when the st_api path is taken, > pipe_screen::update_buffer is no longer got called. And the caller of > pipe_screen::flush_frontbuffer becomes co state trackers instead of > state trackers. > > In st_api, the co state trackers are responsible for representing > windows/pixmaps/pbuffer as a set of pipe_textures (color buffers, > depth/stencil, ...) to the state trackers. In DRI2, this is done > through DRI2GetBuffers and winsys_handle. In software rasterizer (or > DRI1?), this is done by having co state trackers allocate a set of > private pipe_textures. In both cases, the pipe_textures are created > as > needed. That is, if the state trackers draw only to the back buffer, > the front buffer will not be creatd. > > At MakeCurrent, the state trackers (st/mesa and st/vega) are given an > st_framebuffer_iface. The state trackers retrieve the pipe_textures > of > a window/pixmap/pbuffer mentioned above through this interface. Other > than retrieving the pipe_textures, to support front buffer rendering, > the state trackers should call st_framebuffer_iface::flush_front > when it > has something to display. > > The implementation of st_framebuffer_iface::flush_front again > depends on > the window systems. In X11 with DRI2, it is no-op if the front buffer > passed to the state trackers is real; Otherwise, it calls > DRI2CopyRegion to copy the contents from the fake front buffer to the > real front one. > > In X11 with software rasterizer, the co state tracker is responsible > to > display its private pipe_texture to a X drawable. With the merge of > gallium-sw-api-2, this is made really easy by calling > pipe_screen::flush_frontbuffer. > > The last patch of the series converts st/glx to use st_api. The > diff is > cleaner than the diff to st/egl. It is a quick conversion to help see > the design of st_api in work. There should be bugs, but the simple > demos I tested all work. The other patches are constrained to EGL and > any regression outside EGL is considered a bug. > > If you read this long because of the mention of EGLImage in the > subject, > you get to have some fun with progs/es1/xegl/texture_from_pixmap as a > thank-you gift :)
Thanks for doing this Chia-I, also a very excellent summary. Last time we talked about st_api IIRC we both agreed that the way we implemented EGLImage was wrong. However I think that we have waited long enough to move the state trackers over to st_api. Would it to much trouble for you if we didn't do EGLImage in the first gallium-st-api feature branch? My feeling is that they are two separate issues and I think we should be able to quickly resolve moving the state trackers over to st_api and then move on to EGLImage. Looking at the patches the only affected one is the VG state tracker while the rest should just be not to apply the EGLImage related patches. I can do this later tonight and send out a series and give you something to work on. I really want to move the state trackers over to st_api and I don't want the EGLImage issues holding us back. I also think that that part of the patch series looks excellent and I don't foresee any difficulties getting this merged ASAP. Again thanks for doing this I know the inter state tracker interactions are a mess. 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
