Announcement

Collapse
No announcement yet.

Mesa, Wayland, X Will Get Some Summer Love

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

  • phoronix
    started a topic Mesa, Wayland, X Will Get Some Summer Love

    Mesa, Wayland, X Will Get Some Summer Love

    Phoronix: Mesa, Wayland, X Will Get Some Summer Love

    Google today has announced their 2011 student projects for the Google Summer of Code marathon. Four of the X.Org / Mesa / Wayland projects were accepted. Listed below are the accepted projects and a few notes...

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

  • Veerappan
    replied
    Originally posted by tball View Post
    But this would only work if we had an OpenCL st on galium, which we do not have unfortunately.

    And I think we are still far from having an OpenCL st.
    There may still be a lot of work required, but at least the OpenCL state tracker is one of the GSoC projects for this year, which means that at least some work will get done on it.

    Leave a comment:


  • tball
    replied
    Originally posted by Veerappan View Post
    So a related question: If a VDPAU state tracker is developed for Gallium, is it possible to do a pass-through to an appropriate library?

    Basically the video application would interface with VDPAU, VDPAU would actually be a state tracker, but it would just pass all VP8 decoding duties on to the VP8 decoding library which would just use OpenCL to do the work?

    It isn't the most efficient way of doing things (VDPAU state tracker -> libvpx -> OpenCL state tracker -> TGSI), but it would possibly ease the initial development burden, since someone wouldn't also have to bring up a codec-specific video decoder at the same time they do the VDPAU work.

    Then, any codecs which have OpenCL/GLSL implementations available could be quickly brought up in st/VDPAU, and in the future pure Gallium versions could be made if performance is an issue.
    But this would only work if we had an OpenCL st on galium, which we do not have unfortunately.

    And I think we are still far from having an OpenCL st.

    Leave a comment:


  • runeks
    replied
    Originally posted by madbiologist View Post
    OK, I'm confused. It looks like there is a 5th X.Org project implementing hardware accelerated VP8 video decoding for Gallium3d using a Gallium3D state tracker which utilises VDPAU - see http://www.google-melange.com/gsoc/o.../gsoc2011/xorg and http://www.google-melange.com/gsoc/p...ricgrange/1001

    Have I missed something?
    Awesome!

    Looks like it got accepted after all.

    Leave a comment:


  • madbiologist
    replied
    OK, I'm confused. It looks like there is a 5th X.Org project implementing hardware accelerated VP8 video decoding for Gallium3d using a Gallium3D state tracker which utilises VDPAU - see http://www.google-melange.com/gsoc/o.../gsoc2011/xorg and http://www.google-melange.com/gsoc/p...ricgrange/1001

    Have I missed something?

    Leave a comment:


  • Veerappan
    replied
    Originally posted by MostAwesomeDude View Post
    I would like to have a VDPAU video decoder simply so that people that write video players (mplayer, VLC, etc.) do not have to adapt to Yet Another Video Backend. Additionally, finishing and deploying pipe_video_context has been a todo item for years, and it'd be nice to actually complete that.
    So a related question: If a VDPAU state tracker is developed for Gallium, is it possible to do a pass-through to an appropriate library?

    Basically the video application would interface with VDPAU, VDPAU would actually be a state tracker, but it would just pass all VP8 decoding duties on to the VP8 decoding library which would just use OpenCL to do the work?

    It isn't the most efficient way of doing things (VDPAU state tracker -> libvpx -> OpenCL state tracker -> TGSI), but it would possibly ease the initial development burden, since someone wouldn't also have to bring up a codec-specific video decoder at the same time they do the VDPAU work.

    Then, any codecs which have OpenCL/GLSL implementations available could be quickly brought up in st/VDPAU, and in the future pure Gallium versions could be made if performance is an issue.

    Leave a comment:


  • MostAwesomeDude
    replied
    Originally posted by Veerappan View Post
    It sounds like a good project, but I'd also be willing to work with him on the VP8 OpenCL port (not mentor/mentee necessarily, just working together). If the OpenCL Gallium state tracker gets finished, there's no real need to get a VP8/Gallium state tracker up and running. We should be able to extract the needed performance out of the OpenCL version without having to translate it to a state tracker. And then the BSD/Solaris/etc. people can benefit from the work as well.
    I would like to have a VDPAU video decoder simply so that people that write video players (mplayer, VLC, etc.) do not have to adapt to Yet Another Video Backend. Additionally, finishing and deploying pipe_video_context has been a todo item for years, and it'd be nice to actually complete that.

    Leave a comment:


  • Veerappan
    replied
    Originally posted by 89c51 View Post
    didn't you just did/completed this a few weeks back???
    I completed my thesis, but there's still work to do on the VP8 CL decoder port to get it up to acceptable performance.

    Leave a comment:


  • 89c51
    replied
    Originally posted by Veerappan View Post
    It sounds like a good project, but I'd also be willing to work with him on the VP8 OpenCL port (not mentor/mentee necessarily, just working together).
    didn't you just did/completed this a few weeks back???

    Leave a comment:


  • Veerappan
    replied
    Originally posted by smitty3268 View Post
    according to the submitter.

    http://lists.freedesktop.org/archive...il/007055.html

    I hope he does look into the EVoC, it sounded like a good project.
    It sounds like a good project, but I'd also be willing to work with him on the VP8 OpenCL port (not mentor/mentee necessarily, just working together). If the OpenCL Gallium state tracker gets finished, there's no real need to get a VP8/Gallium state tracker up and running. We should be able to extract the needed performance out of the OpenCL version without having to translate it to a state tracker. And then the BSD/Solaris/etc. people can benefit from the work as well.

    Leave a comment:

Working...
X