2009/4/9 Zou, Nanhai <[email protected]>: >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] On >>Behalf Of Stephane Marchesin >>Sent: 2009年4月9日 15:20 >>To: Zou, Nanhai >>Cc: Corbin Simpson; Denis Martinez; [email protected] >>Subject: Re: [Mesa3d-dev] Google Summer of Code >> >>On Thu, Apr 9, 2009 at 08:49, Zou, Nanhai <[email protected]> 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. >
If you want to commit to using the Gallium infrastructure then yes we can all share some code. I am assuming Intel hardware only does IDCT+MC and you want to support VAAPI because you can use the IDCT entry-point. In that case you can at least reuse the scaling and colour conversion code which runs on the GPU, or you can write your own code that uses overlays if you want. Any driver that does Xv Textured Video can share this part of the code. If in the future you want to support VDPAU you can reuse the CPU bitstream parsing code at least since your hardware doesn't decode bitstreams. > So if the language can provide data element like vec16 or even vec32 vec64 > that would be nice. We only have vec4 because you have to remember that we don't use Nvidia's dedicated decoding HW currently, just the GPU and its vertex and fragment shaders. You don't have to reuse that code if you have dedicated HW and know how to use it, but it is available as a GPU fallback. Also note that a lot of this code I haven't pushed yet because I'm extremely busy unfortunately at the moment. The current code in mesa master is not as easy to reuse as it should be, but I'm hoping to have it all sorted out in the next few weeks and make it easier for everyone. Regards, Y ------------------------------------------------------------------------------ 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
