Announcement

Collapse
No announcement yet.

AMD Releases Open-Source R600/700 3D Code

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

  • I honestly still have no idea what you are talking about. WHAT IS THE NV LIBRARY YOU ARE SAYING WE NEED TO COMPETE WITH ?

    When you talk about our technology, I *think* you're talking about our transcoding app, which runs over the Stream tools on the proprietary driver, so maybe you're also talking about ffmpeg using CUDA over the NVidia proprietary driver today ?
    Last edited by bridgman; 01-03-2009, 02:55 AM.

    Comment


    • I'm sorry, I just spent another half hour going through the links you posted and I still have no idea what that "NV library" is. It seems pretty clear that you want us to add GPU-assisted transcoding to the ffmpeg stack but I don't think anything like that exists for NVidia today either, so presumably we're talking about something else ??

      Hopefully you can shed some light. Will check back in the morning.
      Last edited by bridgman; 01-03-2009, 03:19 AM.

      Comment


      • Originally posted by bridgman View Post
        I'm sorry, I just spent another half hour going through the links you posted and I still have no idea what that "NV library" is. It seems pretty clear that you want us to add GPU-assisted transcoding to the ffmpeg stack but I don't think anything like that exists for NVidia today either, so presumably we're talking about something else ??

        Hopefully you can shed some light. Will check back in the morning.

        Maybe he mean VDPAU from NV. ATI has Currently no real HW Acceleration and for XvBA there are no headers or smt like that for use it ( if its Wrong im sorry but i cant find anything about this) .

        Comment


        • why :angry: , OC its Stream and CUDA, unless theres another set of APIs im not aware of as yet, not every reader here or elsware have degrees in computer sciences as i assume you do, but thats no reason to be getting angree at people

          Don/neuron2 that produces the DGAVCDecNV and DGVC1DecNV
          http://forum.doom9.org/showthread.php?t=141104
          http://forum.doom9.org/showthread.php?t=142961

          said to me ..."Nvidia has a fine video decoding library and so I make use of it because libavcodec has problems that make it unsuitable for continued development.

          So, for me, it's just going to be Nvidia, unless and until ATI make available a video decoding library, and not just a bunch of low-level functions.

          Don "

          and that seems to be the general feeling in the doom9 and other related messageboards threads, clearly someone in ATI needs to convince these developers of the popular video apps, to work with and provide mentoring and feedback.

          the same for the linux HD video devs too, its not rocket science and no need to get or show anger here, you dont need to agree with my oppinion OC, mearly take it into consideration, and perhaps profit from it in the long term with better focus to those devs that can help advocate and produce long term apps results or continue on the current path and have these devs and users ignore ATI as they are doing now....
          Last edited by popper; 01-03-2009, 03:37 AM.

          Comment


          • Originally posted by popper View Post
            ......
            do you mean VDPAU from Nvidia ? ATI has SMT like this longer as Nvidia but not announced yet or give header files http://www.phoronix.com/scan.php?pag...vmc_xvba&num=1

            Comment


            • Originally posted by bridgman View Post
              I'm sorry, I just spent another half hour going through the links you posted and I still have no idea what that "NV library" is. It seems pretty clear that you want us to add GPU-assisted transcoding to the ffmpeg stack but I don't think anything like that exists for NVidia today either, so presumably we're talking about something else ??

              Hopefully you can shed some light. Will check back in the morning.
              I'm guessing he's just talking about VDPAU, I wouldn't worry about trying to decode that rambling if I were you.

              Comment


              • Originally posted by Nille View Post
                Maybe he mean VDPAU from NV. ATI has Currently no real HW Acceleration and for XvBA there are no headers or smt like that for use it ( if its Wrong im sorry but i cant find anything about this) .
                Hi Nille, yes it might indeed be VDPAU that Don/neuron2 was refering to see:
                http://forum.doom9.org/showthread.ph...85#post1228785

                however he's not around right now to clarify the question, but
                what ever current NV means these doom9 devs are using, they are producing results people want/need, and people are starting to consider buying the cards these HD video apps are working with to speed up their video processing etc, thats the whole point, the end result and speed matters,not how you get to that point... if you even can with the HW brand and SW you have available.

                its not just transcoding, its any and all options that your average user takes to get the end result, if any part of the workflow can be passed off to the GPU, thats more spare cycles for the CPUs to do other related video procesing stuff in a given timeframe, if that makes sense to you!.
                Last edited by popper; 01-03-2009, 04:31 AM.

                Comment


                • Originally posted by smitty3268 View Post
                  I'm guessing he's just talking about VDPAU, I wouldn't worry about trying to decode that rambling if I were you.
                  you consider asking for, and airing the subject of GPU assisted HD video processing with the readers here rambling ?, very odd.

                  "he's just talking about VDPAU" thats what message boards are for are they not ?, is "VDPAU" and "transcoding" so common now that every reader knows what that is, and how you use it, LOL

                  i take it then that you dont care about any potential future ATI assisted GPU code (whatever that might be, if any)being written, and diffs against the current FFMPEG codebase being submitted.

                  Comment


                  • Originally posted by popper View Post
                    why :angry: , OC its Stream and CUDA, unless theres another set of APIs im not aware of as yet, not every reader here or elsware have degrees in computer sciences as i assume you do, but thats no reason to be getting angree at people

                    Don/neuron2 that produces the DGAVCDecNV and DGVC1DecNV
                    http://forum.doom9.org/showthread.php?t=141104
                    http://forum.doom9.org/showthread.php?t=142961

                    said to me ..."Nvidia has a fine video decoding library and so I make use of it because libavcodec has problems that make it unsuitable for continued development.

                    So, for me, it's just going to be Nvidia, unless and until ATI make available a video decoding library, and not just a bunch of low-level functions.

                    Don "

                    and that seems to be the general feeling in the doom9 and other related messageboards threads, clearly someone in ATI needs to convince these developers of the popular video apps, to work with and provide mentoring and feedback.

                    the same for the linux HD video devs too, its not rocket science and no need to get or show anger here, you dont need to agree with my oppinion OC, mearly take it into consideration, and perhaps profit from it in the long term with better focus to those devs that can help advocate and produce long term apps results or continue on the current path and have these devs and users ignore ATI as they are doing now....
                    Ah, OK. You're talking about the CUDA vs Stream computing on GPUs.

                    I agree that CUDA seems to have a much stronger mind share right now, for whatever reason.

                    I haven't tried messing around with either so I can't say much on the subject. Except that I really hope they both just die and OpenCL takes their place as an open (and compatible) standard.

                    Comment


                    • Originally posted by popper View Post
                      you consider asking for, and airing the subject of GPU assisted HD video processing with the readers here rambling ?, very odd.
                      ...
                      i take it then that you dont care about any potential future ATI assisted GPU code (whatever that might be, if any)being written, and diffs against the current FFMPEG codebase being submitted.
                      Not at all, I just found that post in particular hard to read and confusing. Perhaps "rambling" was the wrong description. I'm guessing that maybe you aren't a native english speaker?

                      More to the point, I didn't feel it really added much to the discussion. I'm sure bridgeman is very aware of all the people who want accelerated video decode, and if he is spending 30 minutes looking through a single post which I figured was just telling him what he already knew then I figured he should just drop the matter

                      I think adding some OpenCL code to the FFMPEG decoders is a pretty good idea, but I'm not really sure I see it as AMD's responsibility. OpenCL is a standard, and I think the FFMPEG devs probably have a better idea about how to write a codec than AMD does. Certainly if you look at their transcoding tool on the windows 8.12 drivers I think you may want to keep AMD as far away as possible and have them stick to the underlying video driver code
                      Last edited by smitty3268; 01-03-2009, 04:38 AM.

                      Comment


                      • Originally posted by smitty3268 View Post
                        I agree that CUDA seems to have a much stronger mind share right now, for whatever reason.
                        Nvidia has a better Marketing. You hear anywhere from Nvidia and CUDA and ATIs Steam promo Software is Folding@Home and the Crappy AVIVOConverter.

                        Comment


                        • "I'm sure bridgeman is very aware of all the people who want accelerated video decode" i wouldnt make that assumption though, if bridgeman is one of several high ranking people inside ATI/AMD, its more likely he and they are mostly only hearing the commercial vendors wants, and generic 3D linux driver mantra.

                          knowing that a high % of people want some form of video processing is one thing,picking the right app (FFMPEG)to support and show off your HW is another matter all together.

                          i find the "you want Transcoding" rather telling, as theres far more to video processing than mearly transcoding, and it comes down to prioritys again and how you support your end game.

                          the windows AVIVO internal driverset transcoder was a real messy implimentation,the old 2005 stand alone AVIVO was a far betetr idea thats for sure ,and its results are bad when compared to the lowest comparable x264 settings, however, for "quick and dirty" and remember its still only using the CPU, no matter what the ATI/AMD PR try and tell you, it can still take a 90minute HD AVC H@L4.1 MKV and transcode it to an xbox360 VC1 WMV container in 20minutes on a simple core2 dual 2GHz machine, good enough for your tversity streamed 360.

                          with some work, you can also bypass the internal 4 year old childrens GUI with virtually no codec parameta output control, and just use all the ATI AVIVO installed directshow drivers directly to make a working graph, and improve the output etc for quick HD 360 streaming use, but thats OT (but related)here....

                          im not asking that he/they write all the optimised SIMD code for FFMPEG inclusion, mearly supply a good fully working example that improves/provides frame accurate stream decoding and MBAFF and PAFF at the very least, OC AVCHD and AVC intra lossless would give many more semi pro people reason to look at ATI/AMD GPUs

                          that simple base code wouldnt need some new set in stone linux HD Video API, but would give masses of people around the world a good reason to give ATI a fighting chance in the PR and long term HD video processing mindset.

                          im not fully up on OpenCL but i seem to remember that ATI current implimentation isnt working right now,or in the near future, and even then, OpenCL doesnt and isnt intended to cover all the tipical HD video stream processing you might expect today anyway !

                          but OC if someone patchs OpenCL ATI into the FFMPEG framwork, and people get to save 10% of their time on a given workflow because of it, then thats a good thing too.
                          Last edited by popper; 01-03-2009, 06:08 AM.

                          Comment


                          • Thanks popper, that answered my question. I put up the "getting mad" icon because I kept asking "what is this library you say we need" and you just kept telling me how great it would be for us to do... whatever it was...

                            The library appears to be an NVidia-supplied Windows-only binary called NVCUVID, which allows a CUDA program to use the VP2 dedicated video processor (like one piece of our UVD) to do the initial decoding of H.264 or VC-1 frames followed by CUDA code doing motion comp and filtering. The CUDA video program can either display the decoded frames through DX or return the frames to the calling application. The second option is obviously what a ripper/frameserver would want.

                            This collection (CUDA run time + NVCUVID binary + CUDA video decode program) is then built into a frame serving program written by Don Graft (neuron2 on the doom9 forum), called either DGAVCDecNV or DGVC1DecNV depending on whether you are using the AVC (H.264) or VC-1 version.

                            The announcement talks about it being cross-platform so presumably it may show up on Linux or MacOS at some point.
                            Last edited by bridgman; 01-03-2009, 02:33 PM.

                            Comment


                            • Originally posted by bridgman View Post
                              The announcement talks about it being cross-platform so presumably it may show up on Linux or MacOS at some point.
                              I wonder what license nVidia put on them.

                              Comment


                              • The library itself is binary so it is presumably covered by the same EULA as the rest of the binary driver. The header files etc... are covered by NVidia's usual open source license, which is a slightly modified MIT license (looks like the one SGI used to use).

                                EDIT - popper, did you make another (long) post around 8 AM ? I can't find it anywhere although I have the notification email from it.

                                I thought the post was pretty good, although you may still be missing that we are arguing on the same side. I was arguing AGAINST investing in a vanilla MPEG2/XvMC implementation because I felt that time would be better spent working on code which would work with H.264 and VC-1.
                                Last edited by bridgman; 01-03-2009, 03:13 PM.

                                Comment

                                Working...
                                X