[Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pip
Christian König
deathsimple at vodafone.de
Tue Apr 26 11:38:10 PDT 2011
Am Dienstag, den 26.04.2011, 17:53 +0000 schrieb younes.m at gmail.com:
> Hi Christian,
>
> Thanks for spending so much time on continuing this. I haven't really
> touched it since you started, but someone else had some patches for
> basic NV50 support. I don't recall who but I hope they can comment and
> are interested in getting their changes merged. Also, your
> implementation of interlaced MC breaks older chips that lack shader
> control flow if I'm not mistaken, but that can probably be fixed
> without much trouble.. Finally, someone else (Jimmy Rentz) had some
> patches that implemented hardware decoding on NV40 chips, but they
> were never merged into nouveau DRM and the pipe-video patches won't
> apply anymore anyhow. Those changes required a bit of work in
> pipe-video to support planar surfaces, but it worked quite well with
> the old vl_compositor. Recently Ben Skeggs added HW decoder bits to
> nouveau's DRM so if anyone is motivated enough to rework the userspace
> side it will require proper planar surface support in pipe-video.
> (This is just an FYI for anyone who is paying attention to
> pipe-video.)
>
> Cheers.
If I remember correctly Bryan Cain was working on getting this to work
again on NV50, he had MC working, but was struggling with the iDCT code.
I also stumbled over the issue of planar texture resources, and solved
it by implementing an abstraction class that uses up to three separate
textures to emulate the behaviour of an YV12 or NV12 texture. If a
hardware driver has native support for planar buffers it should be easy
to override the creation function and use a native buffer instead.
So things like: native idct -> shader base mc or shader based idct ->
native mc should now be easily possible. But there is still allot of
work todo.
Regards,
Christian.
More information about the mesa-dev
mailing list