>-----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. > >> 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. >> 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? 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. Thanks Zou Nan hai > >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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
