Hi Keith, Thanks for having a closer look.
On Thu, Feb 4, 2010 at 9:31 PM, Keith Whitwell <keith.whitw...@googlemail.com> wrote: >> 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. Yeah, right. If there will still be concerns for st/wgl users, I can also postpone the elimination of st_public.h. >> 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? The interface will be implemented by KHR-API state trackers such as OpenGL or OpenVG. It will be used by window-system state trackers such as EGL or GLX (or DRI) that want to manage KHR APIs. It makes the communicaion between a KHR-API state tracker and a window-system state tracker possible, and it does not go down below that layer. The interface is a superset of st_public.h, which supports basic functions such as creating a KHR-API context, bind a context to a window/pixmap, and etc. The distinguishing features the new interface provides are * A single window-system state tracker can manage one or more KHR-API state trackers at the same time (e.g. OpenGL and OpenVG at the same time) * Resource sharing between the window-system state tracker and the KHR-API state tracker(s) The second feature is a natural desire because there can now be multiple KHR-API state trackers. The only callbacks in the interface that has the concept of a "current" context are st_context_iface->make_current and st_context_iface->get_current. There was some discussions listed as Issue 3 in the DESIGN file. With that change and some clarification in the document, other styles of rendering API (such as raw pipe_context) may implement the interface and be bootstrapped by EGL too. > 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? There should be no such need. The interface is "horizontal" between state trackers. It does not descend into lower layers such as pipe_context. As Jakob drafted the first version of the interface, I believe he also wanted to remove "screen->flush_front" and "screen->update_buffer". These two callbacks do become unnecessary because of the new st_framebuffer_iface, which I think is a step forward. -olv ------------------------------------------------------------------------------ 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
