Announcement

Collapse
No announcement yet.

Handbrake 0.9.9 Supports OpenCL Offloading

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

  • Handbrake 0.9.9 Supports OpenCL Offloading

    Phoronix: Handbrake 0.9.9 Supports OpenCL Offloading

    The Handbrake open-source video transcoder program now supports using OpenCL for accelerating certain operations along with introducing other new features to its brand new 0.9.9 release...

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

  • #2
    Looks like the OpenCL part is windows only for now.

    Comment


    • #3
      Very good news. It's always nice to see OpenCL being used on Linux. Hopefully Blender Cycles will support it soon too.

      Comment


      • #4
        Originally posted by wargames View Post
        Very good news. It's always nice to see OpenCL being used on Linux. Hopefully Blender Cycles will support it soon too.
        Hmm I'm not seeing opencl support for linux anywhere at the handbrake website. When you go to the OpenCL beta download page all of the binaries are windows only. I dont think linux is getting the opencl part at this time. So this article is kind of misleading.

        Comment


        • #5
          Originally posted by philip550c View Post
          Hmm I'm not seeing opencl support for linux anywhere at the handbrake website. When you go to the OpenCL beta download page all of the binaries are windows only. I dont think linux is getting the opencl part at this time. So this article is kind of misleading.
          People are not reading the announcement very carefully.
          1. HandBrake OpenCL is Beta
          2. It's not in the 0.9.9 release

          As a rule, HandBrake doesn't release major features till they work on *all* platforms we claim to support (windows, osx, linux). So when it's ready, it should be working on all. Intel QuickSync is also in the pipeline.

          Here's the actual announcements if you care to get it from the source http://handbrake.fr/news.php

          Comment


          • #6
            It would be nice to see some benchmarks. It seems that the supported operations are cropping and scaling.

            Given that the PCI transfer is extremely expensive, and scaling and cropping rather cheap operations, I'm surprised that this is worthwhile.

            On the other hand, it's probably just a first step, with more complex operations planned in the future.

            Comment


            • #7
              when is the 1.0 coming out?

              Comment


              • #8
                Thank you AMD.

                Comment


                • #9
                  Originally posted by pingufunkybeat View Post
                  It would be nice to see some benchmarks. It seems that the supported operations are cropping and scaling.

                  Given that the PCI transfer is extremely expensive, and scaling and cropping rather cheap operations, I'm surprised that this is worthwhile.

                  On the other hand, it's probably just a first step, with more complex operations planned in the future.
                  You have to transfer the video to the graphics card anyway because of the connection to the display.

                  The most optimal way would be to load the video into the graphics card memory and decode, composite and post-process on the graphics card. The graphics card is much better suited for graphics calculations and it frees the CPU for other tasks.

                  Comment


                  • #10
                    Originally posted by plonoma View Post
                    You have to transfer the video to the graphics card anyway because of the connection to the display.
                    But surely handbrake doesn't need to do this often, as it's a transcoding program, not a video player.

                    Comment


                    • #11
                      I hope 1.0 will support WebM with VP9 and Opus.

                      Comment


                      • #12
                        Combined with accelerated video decoding, it makes sense to offload more stuff to the GPU. This way all CPU cycles can be devoted to encoding, and the bus traffic is minimal. Handbrake would only need to push the compressed source video data to the GPU and would read back cropped and scaled frames, and encode these. I'm sure that is what it is doing...? The release notes aren't very clear about it.
                        Last edited by brent; 05-21-2013, 10:25 AM.

                        Comment


                        • #13
                          Originally posted by JohnAStebbins View Post
                          People are not reading the announcement very carefully.
                          1. HandBrake OpenCL is Beta
                          2. It's not in the 0.9.9 release

                          As a rule, HandBrake doesn't release major features till they work on *all* platforms we claim to support (windows, osx, linux). So when it's ready, it should be working on all. Intel QuickSync is also in the pipeline.

                          Here's the actual announcements if you care to get it from the source http://handbrake.fr/news.php
                          Interesting you would say openCL 1.2 and NVidia in the notes. NVidia as of right now only supports 1.1. What 1.2 features are being used (if any).

                          Comment


                          • #14
                            Originally posted by pingufunkybeat View Post
                            It would be nice to see some benchmarks. It seems that the supported operations are cropping and scaling.

                            Given that the PCI transfer is extremely expensive, and scaling and cropping rather cheap operations, I'm surprised that this is worthwhile.

                            On the other hand, it's probably just a first step, with more complex operations planned in the future.
                            It actually makes sense, especially for AMD whose future APU architectures will have shared CPU/GPU memory addressing. Currently, although they share physical memory, there's still a copy involved.

                            Like you said, it makes less sense for discrete graphics cards.

                            Comment


                            • #15
                              Originally posted by pingufunkybeat View Post
                              It would be nice to see some benchmarks. It seems that the supported operations are cropping and scaling.

                              Given that the PCI transfer is extremely expensive, and scaling and cropping rather cheap operations, I'm surprised that this is worthwhile.

                              On the other hand, it's probably just a first step, with more complex operations planned in the future.
                              Well, just tried a couple of encodes on my 8350/titan system. Didn't make a whole lot of difference on a quality based encode, resized from 1080 to 720 with cropping. With openCL 20m32s, without openCL 20m3 seconds. It was using the Titan but barely, gpu load never exceeded 9%. Now QuickSync accelerated on the other hand......6m5s
                              Last edited by deanjo; 05-21-2013, 11:32 PM.

                              Comment

                              Working...
                              X