On Tue, Mar 3, 2015 at 10:43 AM, Chad Versace <chad.vers...@intel.com> wrote: > On 03/02/2015 09:36 PM, Dave Airlie wrote: >> On 3 March 2015 at 13:57, Dave Airlie <airl...@gmail.com> wrote: >>> >>> Okay I've revised this to add some more info to the interface, >>> essentially I need to get the fourcc back so I can later pass >>> it across the "wire" to the EGL_EXT_image_dma_buf_import, also >>> the number of planes (though for my usecase I don't care so much). >>> >>> The problem with EGL_MESA_drm_image is that I've no idea how to retrieve >>> the internal format of an image so I know what to tell the other side, >>> since I just create a normal 2D texture and want to export it, >>> I need to know what format mesa internally picked for it. This works >>> out the fourcc and returns it. >>> >> >> While talking to krh on irc he mentioned that maybe I should skip egl images >> >> and go straight to the texture id->dma-buf extension, >> >> again any opinions from anyone in the area would be useful. > > Please use EGLImages as the import/export object. That provides > consistency with existing similar EGL APIs. And it allows a clean > separation between EGL-aware code and GL-aware code in applications > and compositors. > > For what it's worth, extensions in this area being developed by Google's > Chrome OS team also use EGLImages as the transport object.
We can't both implement EGLImages in a compliant way *and* use them for cross-process sharing like we do. The spec language around orphaning and siblings is obscure, but the idea is that whenever you add a sibling (another client API object, eg a texture or a vg renderbuffer) the contents become invalid. The intended use case is that you create all siblings up front and then start using them. For example, to share an image between VG and GL, you create the VG buffer, then the EGLImage and then the GL texture. Implementations will defer allocation until all the siblings are set up and then only once you start rendering allocate the memory. This allows the implementation to accommodate constraints from all siblings. If you add another sibling, the implementation may have to reallocate storage to satisfy new constraints. This clearly isn't compatible with how we create and share EGLImages left and right across process boundaries. Khronos specifically developed EGLStreams as a cross-process color buffer sharing mechanism without pulling in EGLImage as a dependency. Anyway, the damage is done and we can continue digging ourselves deeper into this hole, but we should at least 1) have a good reason why the extra EGLImage indirection is necessary (it also rules out GLX usage) and 2) acknowledge that we're going to continue to rely on our broken EGLImage semantics. Kristian _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev