The VP8 State Tracker That Was Born This Summer

[phoronix]

Phoronix: The VP8 State Tracker That Was Born This Summer

From this year's Google Summer of Code we know that morphological anti-aliasing (MLAA) for Gallium3D was a great success ready to be merged, there was good progress with the OpenCL Gallium3D state tracker, and the remote Wayland Display Server didn't make it too far. But was it a success for the VP8 state tracker for accelerating Google's video codec in Gallium3D with VDPAU? Here's a status update...

http://www.phoronix.com/vr.php?view=OTg0NA

[droidhacker]

So basically... just like every other gsoc project... nothing useful produced and nothing that will ever be completed.

[HokTar]

I feel quite the opposite way. Provided that his patches will be accepted, of course.

Basically, in my understanding of the article, the only reason it doesn't fully work with g3d is the lack of full vdpau support in g3dvl. Which is being worked on by Christian.

So, this will be rather useful if it gets accepted upstream. *Hoping for the best!*

[droidhacker]

I feel quite the opposite way. Provided that his patches will be accepted, of course.

Basically, in my understanding of the article, the only reason it doesn't fully work with g3d is the lack of full vdpau support in g3dvl. Which is being worked on by Christian.

So, this will be rather useful if it gets accepted upstream. *Hoping for the best!*

Noting, of course, that with the "full vdpau support in g3dvl", the need for all of this suddenly vanishes. Where is the benefit? Basically, what was coded up was.... pointless. What is it supposed to do? If the video decode stuff goes into g3d via vdpau, then it will go media player --> VDPAU --> G3D, bypassing this altogether. So what's the point?

[HokTar]

Noting, of course, that with the "full vdpau support in g3dvl", the need for all of this suddenly vanishes. Where is the benefit? Basically, what was coded up was.... pointless. What is it supposed to do? If the video decode stuff goes into g3d via vdpau, then it will go media player --> VDPAU --> G3D, bypassing this altogether. So what's the point?

In my understanding, which might be completely wrong, he implemented vp8 into vdpau. So the point is that vdpau now supports vp8 and with his other patches the media players know about it.
Granted, it doesn't help much with the current g3dvl implementation. In fact, it can do only as much acceleration for vp8 as much is possible for other codecs (using g3dvl, of course).

[droidhacker]

In my understanding, which might be completely wrong, he implemented vp8 into vdpau. So the point is that vdpau now supports vp8 and with his other patches the media players know about it.
Granted, it doesn't help much with the current g3dvl implementation. In fact, it can do only as much acceleration for vp8 as much is possible for other codecs (using g3dvl, of course).

From my understanding, that should only take about 5 minutes to hack in. Just a matter of advertising it to the media players and shipping the data off to the backend.

[smitty3268]

From my understanding, that should only take about 5 minutes to hack in. Just a matter of advertising it to the media players and shipping the data off to the backend.

He also imported and stripped down the libvpx decoder into Mesa's vdpau system, so that it will work. It sounds like the next step is to start rewriting portions of that C code to use TGSI where possible.

[curaga]

So basically... just like every other gsoc project... nothing useful produced and nothing that will ever be completed.

Just curious, would I go into the "not useful" or the "incomplete" category? ;D

[Veerappan]

I can't say I'm that surprised that he didn't finish the decoder. The fact that he managed to get as far as he did is still useful. I'll also have to check out what sort of simplifications/cleanups/optimizations he made. The color space conversion might also be interesting to look at.

I had only 2 months of coding time when I was working on my OpenCL-based VP8 decoder for my master's thesis. I managed to finish the device initialization, and basic kernels for loop filtering, subpixel prediction (motion comp), and the IDCT/Dequant stages. I didn't have much time to do many algorithmic optimizations for the GPU, so the final product ended up being significantly slower than CPU-based decoding. Hopefully future work on the project will speed it up enough to make it worthwhile.