On Thu, Feb 4, 2010 at 3:39 AM, Chia-I Wu <olva...@gmail.com> wrote: > There was a discussion about a new interface, st_api.h, that will replace > st_public.h last month. Comparing to st_public.h, st_api.h allows multiple > current contexts for each rendering API supported. It removes the need for > pipe_screen->flush_front or pipe_screen->update_buffer by making > st_framebuffer > a manager API (EGL, GLX, or DRI drivers) resource. It also defines hooks that > can be used to support resource sharing between the manager API and the > rendering APIs. An example of this resource sharing is texture-from-pixmap: > the hooks allow using a pixmap (manager API resource) as an OpenGL ES texture > image (rendering API resource). > > The current version of st_api.h and an experimental implementation for OpenVG > and EGL is available at > > http://cgit.freedesktop.org/~olv/st_api/ > > The interface is expected to evolve as the implementation takes place. But I > would like to collect more early feedbacks before I start the work. Any > comment is highly appreciated. The experimental implementation for OpenVG > might help get the ideas of the purposes for certain hooks > > http://cgit.freedesktop.org/~olv/st_api/plain/sample-implementation-tmp/0003-st-vega-Implement-st_api-interface.patch > > As st_api.h can be implemented parallelly with st_public.h, a possible route I > would like to take is to (in this order) > > 1. implement st_api.h in OpenVG and OpenGL state trackers > 2. convert st/egl to use st_api.h > 3. convert st/glx and st/dri to use st_api.h > 4. eliminate st_public.h and any use of it
Probably the other major user is st/wgl. If you install mingw, this can be build-tested on linux machines, so you should at least be able to minimize the disruption in that component as well. > It is an incremental process and there should be no unexpected regression. I > will focus more on 1 & 2. 3 & 4 will happen at a later time, as I am not that > familiar with st/glx and st/dri. It would also be great if anyone is willing > to help out. > > There is also one last change to st_api.h that I would like to make. That is, > > * Rename st_context to st_context_iface > * Rename st_framebuffer to st_framebuffer_iface > > There will be some ugly sed works if st_api.h uses the same struct names as > st/mesa and st/vega are. The patch to st_api.h is at > > http://cgit.freedesktop.org/~olv/st_api/plain/sample-implementation-tmp/0002-gallium-Suffix-st_framebuffer-and-st_context-with-_i.patch And I would suggest st/wgl as well... > Any suggestion or a better naming is welcome. > > I had some other questions. It took a little while to understand the scope of this work, but I think I'm there now. This is basically a unifying interface for managing state-trackers of khronos style APIs. Specifically, it is useful for managing APIs with an implicit context parameter, and hence an external MakeCurrent() call, and an external window system binding for SwapBuffers, etc. Is that basically correct? In particular, there don't seem to be any implications from this proposal that go beyond the interaction of context and window-system state-trackers? I'm trying to figure out if I need to look at anything in this from the perspective of anything below the state-tracker level. Are there new winsys interactions as a result of this? Or pipe_screen/context dependencies? Keith ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
