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 :) -- o...@lunarg.com
st-api.tar.gz
Description: Binary data
------------------------------------------------------------------------------ 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
