On Thu, Apr 9, 2009 at 04:09, Roland Scheidegger <[email protected]> wrote: > On 08.04.2009 22:45, Stephane Marchesin wrote: >> On Wed, Apr 8, 2009 at 21:43, Corbin Simpson <[email protected]> >> wrote: >>> Brian Paul wrote: >>>> Denis Martinez wrote: >>>>> Hi! >>>>> >>>>> I'm a GSoC student interested in the Gallium subjects >>>>> which are about the implementation of VDPAU and OpenGL 3.0. >>>>> >>>>> I would like to start learning Gallium3D, so my question is: >>>>> Do you have any useful learning resources to recommend as a starting >>>>> point? >>>>> Also I'm thinking about hacking on Gallium, something not too difficult, >>>>> in order to get started. >>>>> I'm already familiar with C, Xorg, git, compiling/installing, but still >>>>> have a lot to learn about OpenGL. >>>> Hi Denis, >>>> >>>> I'm not too familiar with the VDPAU stuff so maybe someone else can >>>> comment on that. >>> marcheu, ymanton, and I were talking about this a bit ago. Essentially, >>> we have a state tracker/winsys combo called g3dvl (Gallium3D Video >>> Layer) which can be used for XvMC. VDPAU support would require beefing >>> this layer up to the point of being able to decode h.264, Theora, etc. >>> in a big pipeline, and then writing the glue code to connect with the >>> actual VDPAU interface. >>> >> >> Yes, as Corbin said, the plan is two-fold: >> - first, bring g3dvl up to h.264 levels. Some things are "small" and >> can be adapted from MPEG2 (new quantifying schemes and new block sizes >> for motion vectors, new idct...) and some others are bigger >> (supporting multiple reference frames, CABAC decoding, but that one >> has to be done on the CPU anyway, unless you come up with a genius >> idea to do it on the GPU). I would say you "simply" have to go one >> feature at a time until you get mostly complete h.264 (let's be honest >> here - no one implements the full h.264 standard today, heck 16 >> reference frames of 1080p is using up 64Mb of vram in YV12 format >> already so not all cards can !). >> - then add support for an API that actually exposes that new >> functionality. VDPAU is probably our best candidate (short of creating >> our own API, which is a no-no for standardization reasons). >> > What about VAAPI? XvBA? >
- VAAPI has multiple explicit entry stages, which is more complicated to do properly (you can't just have a single entry point for the data in your code with it, you have to implement them all aven if you know they're not going to be useful). That's because it was primarily designed with embedded systems in mind which I think is a mistake (in a year most of those "embedded" systems will be able to do full H.264 in hw). - XvBA is going to be the loser anyway, it has seen no player adoption so far. - On the other hand, VDPAU has a single entry point to which you just feed the data. So you're free to do what you like in between. Furthermore most players already have support for it in mainline. So all in all, as we can't pursue the implementation of 1000 APIs, and for simplicity's sake, VDPAU is the winner here IMO. Stephane ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
