Announcement

Collapse
No announcement yet.

VP8 Over VDPAU In Gallium3D Is Emeric's Target

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic VP8 Over VDPAU In Gallium3D Is Emeric's Target

    VP8 Over VDPAU In Gallium3D Is Emeric's Target

    Phoronix: VP8 Over VDPAU In Gallium3D Is Emeric's Target

    For those that were excited last week by the French student proposing an H.264 VA-API/VDPAU state tracker for Gallium3D that in turn was revised to WebM or Theora acceleration support instead (since no current-generation GPUs have dedicated video decode engines for these formats), Emeric has firmed up his proposal...

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

  • runeks
    replied
    Oh, that's really a shame then. H.264 acceleration is on the X.Org wiki SummerOfCodeIdeas. There's no proposal for a VP8-accelerating state tracker though.
    Also, it says that the student should continue with the aforementioned g3dvl-code (MPEG-2 XvMC), but that didn't seem to be Emeric's idea of it on the mesa mailing list, as far as I've understood.

    Leave a comment:


  • mattst88
    replied
    Originally posted by runeks View Post
    Yep! It would be interesting if Google gave Emeric some sort of response as to why his project didn't get approved. They have approved these kinds of projects before.
    But maybe that's the thing, they've learned how much it takes to actually implement a functioning GPU accelerated video decoder, and they don't think it's possible to do in 12 weeks?

    There was the MPEG-2 XvMC project that didn't seem to finish according to the blog.

    And I've also read about another guy who produced some code for XBMC to enable H.264 acceleration via GLSL, but that didn't produce anything production ready either, even though someone else picked it up later and worked on it some more (here).

    Would definitely be interesting to hear Google's reason for not accepting this project. It would also help future students proposing projects of this kind to know what they should do to get their project accepted.
    It's not Google's decision. It's X.Org's.

    Apparently no mentor volunteered.

    I think there was a big lack of communication.

    Leave a comment:


  • runeks
    replied
    Yep! It would be interesting if Google gave Emeric some sort of response as to why his project didn't get approved. They have approved these kinds of projects before.
    But maybe that's the thing, they've learned how much it takes to actually implement a functioning GPU accelerated video decoder, and they don't think it's possible to do in 12 weeks?

    There was the MPEG-2 XvMC project that didn't seem to finish according to the blog.

    And I've also read about another guy who produced some code for XBMC to enable H.264 acceleration via GLSL, but that didn't produce anything production ready either, even though someone else picked it up later and worked on it some more (here).

    Would definitely be interesting to hear Google's reason for not accepting this project. It would also help future students proposing projects of this kind to know what they should do to get their project accepted.

    Leave a comment:


  • mattst88
    replied
    That's really disappointing. I thought his proposal was very good and had an excellent chance of producing something quite nice.

    Leave a comment:


  • runeks
    replied
    Looks like this didn't make it to the accepted projects ?

    I can't find it in this list at least: http://www.google-melange.com/gsoc/p...oogle/gsoc2011

    Leave a comment:


  • smitty3268
    replied
    Originally posted by bridgman View Post
    I imagine there is a debug mechanism in Mesa to do that already, not sure though.
    This 1 line patch by Marek prints out compiled shader programs, although I'm not actually sure if that is TGSI or something else like classic Mesa IR.

    https://bugs.freedesktop.org/attachment.cgi?id=45557

    Example output:
    https://bugs.freedesktop.org/attachment.cgi?id=45560

    Leave a comment:


  • bridgman
    replied
    The issue is that OpenGL is a Big Honkin' API and therefore needs a Big Honkin' State Tracker. Mesa is a lot bigger and more complex than the video decoder state tracker would be, and you would probably end up having a lot more code supporting GLSL than supporting video decode.

    It's sort of like bringing your house into your car so you can make coffee while you drive -- OK in principle but not so good in practice

    Leave a comment:


  • runeks
    replied
    Originally posted by bridgman View Post
    Actually I was mostly responding to your question about the need to optimize.

    GLSL could probably get you pretty close, if not give you the same performance (although I haven't done enough shader work to be sure). The real issue is that a Gallium3D state tracker uses Gallium3d calls and TGSI shaders by definition, so you probably want to end up with TGSI rather than copying a big heap of code from the OpenGL state tracker (aka Mesa) to convert the shaders from GLSL to TGSI every time you wanted to decode a video.
    Yes, as things stand today it would have to be implemented in TGSI as you say.

    But I guess my point is that if the TGSI code produced from the GLSL code, as you say, doesn't even need any optimizations to perform really well, then maybe the ability to hook in the GLSL compiler into other Gallium state trackers would ease the developing of future state trackers? Or is Gallium just designed in such a way that this cannot be done without creating a mess?
    The GLSL compiler lives in the mesa state tracker right? So if we were to utilize this feature, the GLSL compiler, in another state tracker, we would be creating a new state tracker that is dependant on another state tracker (mesa). But I guess that's not something that is too distant of a concept to Linux; dependencies.
    Of course, it would probably need to be some kind of Just-in-time compiler with code caching, in order to be effective. Which quickly makes it quite of a project in itself.

    Originally posted by bridgman View Post
    There might be (or, more likely a newer talk), but I would have to be at work (with something faster than 24 Kb/s download) to find it before the technology becomes obsolete
    Hehe . If you do find the talk, or any other talk(s) regarding this please do post a link in this thread. The talks usually go into more detail, plus the questions often reflect my own questions on the topic.

    Leave a comment:


  • bridgman
    replied
    Originally posted by runeks View Post
    Although I was actually about to ask how much it would take to make GLSL directly supported in state trackers instead of TGSI. But I guess that leads me to John's response (wrt. optimizing)... <snip> And so, GLSL doesn't really cut it because it abstracts away all the memory management right?
    Actually I was mostly responding to your question about the need to optimize.

    GLSL could probably get you pretty close, if not give you the same performance (although I haven't done enough shader work to be sure). The real issue is that a Gallium3D state tracker uses Gallium3d calls and TGSI shaders by definition, so you probably want to end up with TGSI rather than copying a big heap of code from the OpenGL state tracker (aka Mesa) to convert the shaders from GLSL to TGSI every time you wanted to decode a video.

    Originally posted by runeks View Post
    But I guess it's just a matter of learning TGSI like any other language. I've just only briefly touched on RISC assembly, and that seemed like so much effort for so little. It would probably help if we had some TGSI code already, generated from GLSL to start with though.
    I imagine there is a debug mechanism in Mesa to do that already, not sure though.

    Originally posted by runeks View Post
    Sweet! Looks great! Second page says "GPGPU from real world applications - Decoding H.264 Video" so without knowing much else I'd say it's right on the money. I will definitely be digging into that at some point! Would there happen to be a recorded talk/presentation over these slides somewhere?
    There might be (or, more likely a newer talk), but I would have to be at work (with something faster than 24 Kb/s download) to find it before the technology becomes obsolete

    Leave a comment:

Working...
X