Zou, Nanhai wrote: >> -----Original Message----- >> From: stephane.marche...@gmail.com [mailto:stephane.marche...@gmail.com] On >> Behalf Of Stephane Marchesin >> Sent: 2009年4月9日 15:20 >> To: Zou, Nanhai >> Cc: Corbin Simpson; Denis Martinez; mesa3d-dev@lists.sourceforge.net >> Subject: Re: [Mesa3d-dev] Google Summer of Code >> >> On Thu, Apr 9, 2009 at 08:49, Zou, Nanhai <nanhai....@intel.com> wrote: >>> >>> I have not been looking into gallium support yet. >>> Are you working on software fallback or on some real hardware? >> We have xvmc on top of g3dvl working on nv40-class hardware (and more >> generically, it should work any card which has a gallium driver). >> We've had this since last year's summer of code. Our main purpose is >> to avoid reinventing the wheel with each driver... >> >>> I am now working on HW accelerated media support for our chip(XVMC etc), >>> next >> plan is to support VAAPI. >>> The code is now in our 2D dirver, in freedesktop.org xf86-video-driver . The >> master branch has MC only implement, >>> There is a branch xvmc-vld which support offload mpeg2 decode to GPU from >>> VLD >> entry. >>> Media kernels running on GPU will do MC and IDCT and IQ, fix function unit >> HW will do VLD decode. >> Well, we don't have hw video decoding specs for nvidia/ati (and on >> some hardware we don't even have any video decoding hw), so we use the >> shaders for everything anyway. >> As far as VAAPI goes, someone could add a lib for it on top of g3dvl, >> that's probably the nicest solution. But as I said in the other email, >> the number of VAAPI entry points makes it difficult to implement. In >> reality we don't need all these entry points, only old/embedded >> hardware needs them, and that type of hardware has no gallium support >> anyway. > > You can choose to implement 1 single entry point e.g. VLD. > What I think VAAPI is missing is post processing,However I can talk to > VAAPI people to improve the API, anyway VAAPI is only at version 0.30.
VAAPI is currently "unplanned," which IME typically translates to "patches welcome." Ditto for XvBA. :3 In all honesty, VDPAU is simple, straightforward, and (for once) we're in a position where implementing the nVidia screw-the-standards-let's-write-our-own-standard system actually is possible and full of win, so that's our first target. (Oh, and embedded hardware support could always be added. Gallium pipes for NEON, anybody?) >>> I think merge the VAAPI support into mesa might be a good idea. >> If you don't have gallium for your chip, you have a specific >> implementation then? In which case it doesn't make much sense to merge >> it into mesa... >> > > > Our current XVMC-vld implementation is in the 2D driver. > > I am planning to implement to support VAAPI in a stand alone liberary. > However I am thinking implement VAAPI in mesa may help us to have less > duplicated code, That means support for dri stuff, rendering, multi stream > blending , scaling, subpicture easier. Well, Gallium code's generic, so it does lead to less duplication. Rather than write Intel-specific code, you write Gallium code which all drivers can use, and then beef up the Intel drivers to be able to handle it. >>> However currently we program media kernel with very low level assembly code. >>> I fell it is better we can have some higher level shading language for later >> complex H.264 support and video post processing. >>> But I don't think GLSL like language can generate efficient enough media >> processing code. >>> So I am wondering which kind of programming language are you using for GPU >> media decoding. >> Well we already use a GLSL-like language for that (intermediate >> gallium representation) and we already have a working xvmc >> implementation, so I don't think these concerns hold. > > > Does the XVMC implementation support MC only flag or MC + IDCT? > Is it efficient enough to decode high rate HD content? Yes, yes. > Is it a high level language or you mean you do MC and IDCT with mesa internal > op? > I think a high level language is most useful for performance tuning and > debuging, consider the complexity of H.264 and post processing. > > I have considered using GLSL, but for our media pipeline, > hardware usually run instruction in 16 ways or wider. > So if the language can provide data element like vec16 or even vec32 vec64 > that would be nice. The internal representation used in Gallium is TGSI and it should be sufficient for nearly all your needs. Check out http://www.tungstengraphics.co/wiki/files/tgsi.pdf for the formal specification, or if you'd like more concrete examples, look at src/gallium/auxiliary/tgsi for Gallium's TGSI utilities, or most of the drivers in src/gallium/drivers/* for card-specific TGSI decoders. ~ C. ------------------------------------------------------------------------------ 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
