[Libva] How to detect the type of memory returned...

Gwenole Beauchesne gb.devel at gmail.com
Mon Jun 16 08:30:02 PDT 2014


Hi,

2014-06-16 8:42 GMT+02:00 Rainer Hochecker <fernetmenta at 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


More information about the Libva mailing list