Hi, 2014-06-16 8:42 GMT+02:00 Rainer Hochecker <fernetme...@online.de>: > I am bothering with this as well in the context of XBMC. It is a shame that > libva does not provide any means for interoperation with OpenGL. I don't > consider this pixmap magic happening in vaCopySurfaceGLX a proper way to do > this.
Please don't rely on VA/GLX any more. This is going to die at some point. It was only useful to overcome the needs from proprietary drivers. Nowadays, even the GLX protocol itself is not appealing enough. At best, directly use vaPutSurface() + TFP (EXT_texture_from_pixmap), but an RGBA backing store is not efficient enough, unless you downscale for thumbnailing purposes for instance. > vaDeriveImage is useless without the sse4 copy. What is the view of Intel on > this? Move to the new "buffer export" APIs, which have the benefit to work offscreen. e.g. you can use VA/DRM, export the underlying buffers, import from another process, etc. This makes interop with EGL and OCL more convenient, straightforward and efficient. I have just pushed the necessary code to libva and libva-intel-driver. * The Mesa support is currently available here: <http://cgit.freedesktop.org/~gb/mesa/> ("20.EXT_image_dma_buf_import" branch) It will be refreshed (more explicit extension string, textual refinements to the .spec for upstream). I don't expect changes to the implementation, unless we also fix Mesa's implementation for EXT_image_dma_buf_import #6 conformance, and not #5. Regards, -- Gwenole Beauchesne Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France Registration Number (RCS): Nanterre B 302 456 199 _______________________________________________ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
