On Fri, 2009-04-24 at 00:25 -0700, Gwenole Beauchesne wrote:
> Hi,
>
> Le 23 avr. 09 à 19:14, Rusty Lynch a écrit :
>
> > Caveat:
> > Again, just like with helix, we would still need texture-from-pixmap
> > support and support for passing in a pixmap to libva. Without this
> > then
> > we would have to use the libva method to copy the data out of the
> > hardware and then write that into the 2d texture. I don't know how
> > much
> > of a performance impact that will have.
>
> It's huge. I experimented with vaGetImge() for Flash HD (H.264
> encoded) video playback in Gnash. A single vaGetImage() completes in
> approx. 19 ms for 720x576 clips (~60+ ms for 1080p).
That's what I feared. Perhaps not such a big deal for standard def
content, but the real performance gain is in decoding HD that would
otherwise be impossible.
> Besides, Flash
> requires RGB24 pixels data. It should be possible to composite the
> other way around, that is write a real VA backend and merge other
> Flash elements through vaPutImage() or Subpictures? That sounds much
> less trivial though (I am currently not familiar enough with Gnash
> code).
>
> TFP is the only sane route for OpenGL rendering, unless you implement
> a specific backend/hook for it. e.g. a vaPutSurfaceGL() which takes a
> GL texture id as argument instead, and a vaGetDisplayGL() with a
> Display* and a GLXContext for example.
Having vaPutSurfaceGL()/vaGetDisplayGL() would make life a lot easier.
It's unclear to me how the freedesktop standard is being maintained, but
getting this in the standard would make it easier to beat up (um... i
mean politely ask) the graphics driver team to provide the feature.
--rusty
_______________________________________________
Moblin dev Mailing List
[email protected]
To manage or unsubscribe from this mailing list visit:
https://lists.moblin.org/mailman/listinfo/dev or your user account on
http://moblin.org once logged in.
For more information on the Moblin Developer Mailing lists visit:
http://moblin.org/community/mailing-lists
