On Wed, 2010-03-10 at 20:15 -0800, 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 :)
>
Chia-I,
This is all looking good to me. The code doesn't seem to introduce any
new layering issues or introduce dependencies on existing ones, which
helps with ongoing cleanups.
I did some quick testing with the "linux-debug" target. Gears works,
with and without GALLIUM_WRAP=t. However, demos/singlebuffer seems to
get caught in infinite recursion and segfaults:
Program received signal SIGSEGV, Segmentation fault.
0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
185 {
(gdb) bt
#0 0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
#1 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#2 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#3 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#4 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#5 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#6 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#7 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#8 0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
Keith
------------------------------------------------------------------------------
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
