[Libva] [RFC] OpenGL API extension

[Gwenole Beauchesne]

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

My constraints were:
- A libVA shall not contain both OpenGL and raw X11 code, thus  
requiring libVA split (libva, libva-x11, libva-glx)
- An application can link against both libva-x11 and libva-glx and  
there should be no symbol collision
- A VA backend needs a way to know about the application GLXContext
- A function to copy the whole VA surface to a GL texture is needed,  
there is no partial copy intended

How could this be implemented:
- (a) Direct vaPutSurfaceGLX hook
- (b) GLX texture-from-pixmap extension with the Pixmap rendered  
through vaPutSurface() (NVIDIA)
- (c) GLX texture-from-pixmap extension with the underlying Pixmap  
extracted from the VA Surface (Intel)

Now the following question arises: who implements TFP, the driver or  
libVA? My initial idea was something among those lines in libVA:

if (ctx->vaPutSurfaceGLX)
     return ctx->vaPutSurfaceGLX();

Pixmap pix = get_surface_pixmap();
// ... create, or use cached, glxpixmap
// ... render glxpixmap to GL texture

but it became apparent that some additional data used for caching  
would be necessary. Unfortunately, we can't attach additional data to  
a VASurfaceID since the actual implementation is hidden into the VA  
driver. So, it's up to the VA driver to implement (a), (b) or (c)  
itself, event if two drivers implementing either (b) or (c) would turn  
out to duplicate things from each other, I am afraid.

I have no control over Intel drivers but I was told case (c) could be  
implemented easily. The ideal case would have been to implement (b)  
and (c) directly into libVA as fallbacks if vaPutSurfaceGLX() hook is  
NULL. However, I don't really want to implement hashes, or other data  
structures, just to add private data to a VASurfaceID. IMHO, this  
would complicate libVA for no real gain(?).

I hope I could upload newer libVA, hwdecode-demos, mplayer by the end  
ot the week. So, if you have any comment about the proposed two  
additional functions, you are welcome to speak up now. ;-) This is  
because I intend to use this model in other players.

Note:
- vaPutSurfaceGLX() could become a plain vaPutSurfaceGL() if someone  
foresees, or intends to work on, an OpenGL ES extension. Is this  
desirable?

I have attached an initial patch. It will be split into at least three  
parts when I feel it's good enough and looks OK to others.

Regards,
Gwenole.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 400_libva_glx.patch
Type: application/octet-stream
Size: 15270 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/libva/attachments/20090819/fd2a1475/attachment.obj 
-------------- next part --------------