Announcement

Collapse
No announcement yet.

Will H.264 VA-API / VDPAU Finally Come To Gallium3D?

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

  • #16
    Originally posted by 89c51 View Post
    i made a mistake and thought that the g3dvl project was about h.264
    My point was, what right do you have to complain about other people's projects (especially if you aren't contributing to any projects)?

    Originally posted by Rabauke View Post
    Yes, bridgman, give us an update on the UVD review process.
    And btw, what about Christian König's effort? Did anything of his work materialize yet?
    http://cgit.freedesktop.org/mesa/mesa/log/?h=pipe-video

    Comment


    • #17
      Originally posted by popper View Post
      unfortunately End User's International Inc cant comment on you're speculation until the NDA (No longer Damned Arsed) end's, or a future public statement of that information is released by You in to the public domain as Linux manager in charge and instigator of that data.
      I have no idea what this means

      Originally posted by popper View Post
      so have you actually even started that AMD UVD legal review yet after nearly 12 months of talking about starting it here with me ? i didn't check the dates yet but it (didn't even get passed to the legal team ?) it hadn't even got off the starting block something like 4 months ago now according to a post here.
      Yes, the *technical* review started a few months ago and I posted about that at least once here.

      Not sure why you keep calling it a legal review, this (and most of the IP review work) is primarily technical analysis. I have mentioned that here perhaps a dozen times.

      Comment


      • #18
        Originally posted by mattst88 View Post
        My point was, what right do you have to complain about other people's projects (especially if you aren't contributing to any projects)?
        i am not complaining about anything. if i need a feature i will use the "product" that has it. as simple as that.

        it is just a fact that the open source drivers are not feature compete

        also how sure you are that i am not involved one way or another in projects?? (not that it matters if i do or not)

        Comment


        • #19
          Originally posted by DanL View Post
          I have no issue dressing in drag for good video accel.
          That was a reminder of UVD being available for windumbs since start, and its equivalent for linux only being in plans written by 3rd party(student@now) now. Video accel itself is always good.

          Comment


          • #20
            Originally posted by 89c51 View Post
            also how sure you are that i am not involved one way or another in projects?? (not that it matters if i do or not)
            I'm not sure, but I certainly have noticed an inverse correlation between the number of complaints made and the amount contributed.

            Comment


            • #21
              In the previous thread on this topic it was mentioned that the developers who had originally started a VDPAU implementation were considering moving their work to VA-API.
              Originally posted by tball View Post
              We have worked on a vdpau state_tracker, but are considering moving to vaapi instead due to complications with implementing a brand new bitstream decoder.

              Comment


              • #22
                Originally posted by phoronix
                AMD has also experimented with XvMC for their Gallium3D driver
                Seems like a duplication of effort to me. Wouldn't it be better if AMD just contributed to the r600g driver hosted at freedesktop.org, instead of writing their own Gallium3D driver? Or could it be that phoronix is spreading misinformation again?

                If you spend a little more time on making sure your articles are correct without ambiguity and a little less time on fluffing up your articles with irrelevant stuff just so you can squeeze in more links to yourself, maybe people would start taking phoronix seriously. Just maybe.

                Comment


                • #23
                  Originally posted by 89c51 View Post
                  wasn't there another GSoC project few years back that was trying to do the same thing and in the end we got nothing????
                  The two main projects that I can think of were:
                  1) Younes Manton, GSoC project. g3dvl, already mentioned in this thread
                  2) Robert Rudd @ MIT. Another GSoC project that attempted H.264 decode via GLSL shaders using the ffmpeg/libav framework as a starting base. He got some stuff working, but didn't finish the project. Someone forked his code and at least got it to compile: https://github.com/kasbah/gsoc.

                  Give it a few weeks, and I'll be sending my initial VP8 OpenCL implementation to the WebM mailing list to live in a sandbox while I continue work on it post-graduation. It's functional, but much slower than CPU-only decoding at the moment. It does at least produce correct output... in its own good time.

                  Once its in the sandbox and my thesis is finished up, I wouldn't object to anyone helping me out with getting the performance up to speed.

                  Comment


                  • #24
                    Originally posted by monraaf View Post
                    Seems like a duplication of effort to me. Wouldn't it be better if AMD just contributed to the r600g driver hosted at freedesktop.org, instead of writing their own Gallium3D driver? Or could it be that phoronix is spreading misinformation again?

                    If you spend a little more time on making sure your articles are correct without ambiguity and a little less time on fluffing up your articles with irrelevant stuff just so you can squeeze in more links to yourself, maybe people would start taking phoronix seriously. Just maybe.
                    I think he means r600g. AMD's not writing 'their own' Gallium3D driver. Sigh.

                    Comment


                    • #25
                      Originally posted by plonoma View Post
                      You know what would be really helpful.
                      If they started with doing this with MPEG-1 and 2.
                      Work their way up to the present.
                      AFAIK, MPEG2 works. Christian König has a working XvMC implementation, for r600g. I haven't tested it, but others have, and it's working (not perfectly optimised yet). He also has iDCT working and some other stuff.

                      And why is everybody trying to make H.264 get a foothold on Linux?
                      Please support FLOSS formats/libraries instead of the latest flashy thing like H.264.
                      Most of the steps which any modern high-quality codec does are similar: iDCT, motion compensation, etc. If it's done for H.264, it can be easily ported to other codecs. The main difficulty is getting the infrastructure and a reference implementation down.

                      Comment


                      • #26
                        Originally posted by Veerappan View Post
                        Give it a few weeks, and I'll be sending my initial VP8 OpenCL implementation to the WebM mailing list to live in a sandbox while I continue work on it post-graduation. It's functional, but much slower than CPU-only decoding at the moment. It does at least produce correct output... in its own good time.
                        Now, THAT sounds fantastic! Great work!

                        Now we need Clover

                        Comment


                        • #27
                          Originally posted by Veerappan View Post
                          Give it a few weeks, and I'll be sending my initial VP8 OpenCL implementation to the WebM mailing list to live in a sandbox while I continue work on it post-graduation. It's functional, but much slower than CPU-only decoding at the moment. It does at least produce correct output... in its own good time.

                          Once its in the sandbox and my thesis is finished up, I wouldn't object to anyone helping me out with getting the performance up to speed.
                          Good news, thank you!

                          Let's hope that we'll have an opencl state tracker to actually use it.

                          Comment


                          • #28
                            Originally posted by monraaf View Post
                            Seems like a duplication of effort to me. Wouldn't it be better if AMD just contributed to the r600g driver hosted at freedesktop.org, instead of writing their own Gallium3D driver?
                            Originally posted by mattst88 View Post
                            I think he means r600g. AMD's not writing 'their own' Gallium3D driver. Sigh.
                            I think Michael meant "the Gallium3D driver for their hardware", which a lot of people shorten to "their Gallium3D driver" even if that is not strictly equivalent.

                            Comment


                            • #29
                              Originally posted by Veerappan View Post
                              The two main projects that I can think of were:
                              1) Younes Manton, GSoC project. g3dvl, already mentioned in this thread
                              2) Robert Rudd @ MIT. Another GSoC project that attempted H.264 decode via GLSL shaders using the ffmpeg/libav framework as a starting base. He got some stuff working, but didn't finish the project. Someone forked his code and at least got it to compile: https://github.com/kasbah/gsoc.

                              Give it a few weeks, and I'll be sending my initial VP8 OpenCL implementation to the WebM mailing list to live in a sandbox while I continue work on it post-graduation. It's functional, but much slower than CPU-only decoding at the moment. It does at least produce correct output... in its own good time.

                              Once its in the sandbox and my thesis is finished up, I wouldn't object to anyone helping me out with getting the performance up to speed.
                              did you put your current alpha/beta prototype code on a github or do you intend to soon? and when do you assume your thesis will be done

                              there's all those other bit's and peace's of openCL/Cuda code mentioned on the x264dev logs etc too, it's not clear if they do/cover other stuff besides your "I've managed to convert Subpixel Prediction (sixtap + bilinear), IDCT, Dequantization, and the VP8 Loop filter" routines yet , as no ones bothered to collect them up and list the github etc location's on a web page somewhere

                              Comment


                              • #30
                                Originally posted by plonoma View Post
                                You know what would be really helpful.
                                If they started with doing this with MPEG-1 and 2.
                                Work their way up to the present.

                                And why is everybody trying to make H.264 get a foothold on Linux?
                                Please support FLOSS formats/libraries instead of the latest flashy thing like H.264.
                                How the hell is MPEG-2 "free and open"? It is patented and licensed by MPEG-LA.

                                MPEG-1 is basically MPEG-2 with lower resolution. It doesn't need hardware acceleration anyway.

                                Comment

                                Working...
                                X