On Wed, Feb 24, 2010 at 11:25 AM, Stephane Marchesin <stephane.marche...@gmail.com> wrote: > On Tue, Feb 23, 2010 at 18:05, Chia-I Wu <olva...@gmail.com> wrote: >> Hi list, >> >> We at LunarG are working on resource sharing between EGL and its rendering >> and >> non-rendering APIs. The resource sharing is at the driver level and it >> enables >> us to properly support various EGLImage extensions for EGL/OpenGL|ES/OpenVG >> as >> well as OpenMax's OMX_UseEGLImage. >> >> We would like to formalize our changes to Gallium and the current design >> document is available at >> >> http://www.lunarg.com/wordpress/wp-content/downloads/surface-manager-design.pdf >> >> To summarize, resource sharing between EGL and its rendering APIs (OpenGL ES >> and OpenVG) will be made possible through the switch to st_api.h[1], which >> aims >> to replace st_public.h that is implemented by st/mesa and st/vega. It has >> been >> discussed several times on the list. The list archive should have more >> details >> than the document right now. >> >> The only non-rendering API in existence is OpenMax. What we would like to do >> is to support decoding video frames into texture objects directly, which is >> defined in OpenMax IL through the use of EGLImage. We've picked Bellagio[2] >> for our work. As Bellagio is a 3rd party project, what this means to Gallium >> is that we will work on a new state tracker that grants Bellagio access to >> pipe_textures. >> >> We would like to submit the new state tracker (as well as st_api.h) for >> upstream review & inclusion when we have a working implementation. We think >> it >> is important for us to start our work publicly to make sure we are working in >> the direction that Gallium is moving. It should be beneficial for both Mesa >> and us. We are improving the design document as we progress. Any feedback >> on >> our design and the new state tracker will be appreciated. > I have one comment/question, are you going to use vl for that? It's > obviously intended to target multiple APIs... Generally, OpenMax IL components need not to depend on Gallium3D to use EGLImages as the buffers. But individual IL components like mpeg4 codec and such may choose/need to be compiled separately from Bellagio and use v4l in Gallium3D for hardware acceleration.
As OpenMax IL is not managed by EGL as other rendering APIs are, it is also an interesting question that where do the Gallium3D-based IL components get the pipe_screen/pipe_context in the first place? It is either from EGL or Surface Manager. I am leaning toward Surface Manager to avoid adding another internal interface between EGL and Gallium3D-based IL components. -- o...@lunarg.com ------------------------------------------------------------------------------ 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
