On Fri, Feb 5, 2010 at 7:40 PM, José Fonseca <jfons...@vmware.com> wrote: > On Thu, 2010-02-04 at 21:23 -0800, Chia-I Wu wrote: >> 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. > WGL semantics are similar to GLX -- just different names --, so I don't > expect any problem adapting st/wgl to st_api.h. Leaving it broken is not > an option though, since it is a very important component for us. If you > could do the initial rough conversion of st/wgl to st_api.h I'd gladly > test it and polish it. That would be great.
It is also worth noting that a KHR-API state tracker can support both st_api.h and st_public.h at the same time. This is why window-system state trackers can be migrated to use st_api.h one by one without any breakage. It should hopefully also have less unexpected regressions. > I've looked at http://cgit.freedesktop.org/~olv/st_api/tree/st_api.h , > and all looks very sensible. The only thing I don't understand, perhaps > due to my EGL ignorance, is st_context::lock/unlock_resource(). What do > they exactly accomplish? Is there some EGL visible APIs that map exactly > to this? There are OpenGL ES and OpenVG extensions that add functions taking EGLImageKHR as an argument. The KHR-API state trackers will need to validate and look up the underlying pipe_texture of EGLImageKHR. Conversely, a texture object (type GLuint) or VGImage may be passed to EGL to create an EGLImageKHR. EGL needs to ask the respective KHR-API state trackers to validate the name/handle and return the underlying pipe_texture. The callbacks (lock_resource/unlock_resource) may be simplified to a single reference_resouce (a reference must be added to avoid race). But there is one known use that require a VGImage to be locked. It will cause EGL to return EGL_BAD_ACCESS or OpenVG to return VG_IMAGE_IN_USE_ERROR. >> 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. > screen->flush_front itself may still exist, but indeed the Mesa state > tracker shouldn't call it directly -- it should be st/wgl, st/glx, and > friends. I think st_api's st_framebuffer::flush_front accomplishes this > nicely. > BTW, I'd prefer the name "present" instead of "flush_front". It's a more > common and intuitive name for this operation. I think the name follows how pipe_screen names it. I am quite open to the naming, but maybe we can keep it for a while until pipe_screen renames it, or removes it? -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
