Results 1 to 9 of 9

Thread: The VP8 State Tracker That Was Born This Summer

  1. #1
    Join Date
    Jan 2007
    Posts
    14,827

    Default The VP8 State Tracker That Was Born This Summer

    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

  2. #2
    Join Date
    Oct 2009
    Posts
    2,110

    Default

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

  3. #3
    Join Date
    Dec 2009
    Posts
    338

    Default

    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!*

  4. #4
    Join Date
    Oct 2009
    Posts
    2,110

    Default

    Quote Originally Posted by HokTar View Post
    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?

  5. #5
    Join Date
    Dec 2009
    Posts
    338

    Default

    Quote Originally Posted by droidhacker View Post
    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).

  6. #6
    Join Date
    Oct 2009
    Posts
    2,110

    Default

    Quote Originally Posted by HokTar View Post
    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.

  7. #7
    Join Date
    Oct 2008
    Posts
    3,137

    Default

    Quote Originally Posted by droidhacker View Post
    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.

  8. #8
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,108

    Default

    Quote Originally Posted by droidhacker View Post
    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

  9. #9
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    874

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •