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.

> 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...

> 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.

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

Reply via email to