On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
> 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
Also, libgl-xlib / llvmpipe is getting some rendering errors with these
patches - seems like culling is messed up maybe. This is with a scons
build after adding the missing xm_st.c file.
Does it make sense to push these patches to a public Mesa branch so some
bugfixing can get done?
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
