[Libva] [RFC] OpenGL API extension (v2)

[Gwenole Beauchesne]

Hi,

On Thu, 20 Aug 2009, Yuan, Shengquan wrote:

> On Wed, Aug 19, 2009 at 6:15 AM, Gwenole
> Beauchesne<gbeauchesne at splitted-desktop.com> wrote:
>> Hi,
>>
>> I am experimenting with OpenGL extensions to VA API. I came up with the
>> following two additions, in some <va/va_glx.h>:
>> - vaGetDisplayGLX(Display, GLXContext *); returns a suitable VADisplay for
>> VA API
>> - vaPutSurfaceGLX(VADisplay, VASurfaceID, GLuint texture, unsigned int
>> flags); is used to copy VA API surface to an OpenGL texture
>>
> There are some discussion about XvMCCopySurfaceToGLXPbuffer or
> XvMCCopySurfaceToGLXPixmap a long time ago . Since XvMC/VA and GL/GLX
> context are seperate context, and they need to share the underline
> frame buffer information, it is not easy to implement.

In the worst case, I foresee a default implementation with TFP and FBO. 
Actually, it's just a matter of copying the vdpau-video driver code to 
libVA/GLX when I am satisfied enough with the API.

> Application can vaPutSurface to a pixmap, then use texture_from_pixmap 
> to load texture image. It is the current feasible way to associate a VA 
> surface with a GL context. I will have a sample to demonstrate it.

The problem is some accelerators can render directly to an OpenGL texture, 
or at least there is an efficient way to transfer the VA surface to GL 
texture. Worse, they may not support vaPutSurface(Pixmap,...) at all or 
actually have no working/correct TFP implementation (out of VA context).

So far, I have implemented the previously mentioned functions to two 
drivers. Modified MPlayer is now available here:
<http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/>

If you also have an NVIDIA card + vdpau-video >= 0.4.0, you can try:
$ ./mplayer -vo vaapi:gl -va vaapi /path/to/some/video

or even with some nice reflection effect:
$ ./mplayer -vo vaapi:gl:reflect -va vaapi -fs /path/to/some/video

The current implementation for NVIDIA shows the API is not very convenient 
and probably inhibits some performance. MPlayer CPU usage for VO (video 
output) now jumps to ~20% whereas it's under 1% in normal 2D display. Note 
that a VA driver for another chipset can make this below 5% for both 
cases. That is, 2D or GL rendering perform as well.

Regards,
Gwenole.