Announcement

Collapse
No announcement yet.

C Framework For OpenCL Now Supports Device Fission & Native Kernels

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

  • C Framework For OpenCL Now Supports Device Fission & Native Kernels

    Phoronix: C Framework For OpenCL Now Supports Device Fission & Native Kernels

    The C Framework For OpenCL has reached version 2.0. CF4OCL allows the rapid development of OpenCL host programs in C/C++ while making it easier to provide OpenCL, simplify the analysis of OpenCL environments, etc...

    http://www.phoronix.com/scan.php?pag...4OCL-OpenCL-20

  • #2
    We have better and better developer tools for OpenCL as time goes by, still there is not one single end user software for the masses that makes use of OpenCL. It would be very nice to see OCL support in x264 for example.

    Comment


    • #3
      Originally posted by eydee View Post
      We have better and better developer tools for OpenCL as time goes by, still there is not one single end user software for the masses that makes use of OpenCL. It would be very nice to see OCL support in x264 for example.
      There is already.
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        Originally posted by darkbasic View Post
        There is already.
        It's limited option only for lookahead, and activatable only with a hidden command line switch. At least that's what people say. Performance gain is marginal, the encoding itself doesn't touch the GPU.

        Comment


        • #5
          amd hsa

          Opencl 2.0, the beginning of HSA programming

          How long we have to wait to see programs taking advantage of HSA?

          Does MS Windows or Linux is planned to take advantage of it??

          regards
          tux

          Comment


          • #6
            Originally posted by eydee View Post
            It's limited option only for lookahead, and activatable only with a hidden command line switch. At least that's what people say. Performance gain is marginal, the encoding itself doesn't touch the GPU.
            That's because it doesn't parallelize well, you wouldn't get much speedup or it could even be slower. Ask Veerappan for war stories.

            Comment


            • #7
              Originally posted by eydee View Post
              It's limited option only for lookahead, and activatable only with a hidden command line switch. At least that's what people say. Performance gain is marginal, the encoding itself doesn't touch the GPU.
              https://trac.handbrake.fr/roadmap

              Handbrake 0.10


              General

              Core

              Intel QuickSync Video Encode / Decode support.
              Windows only currently. We hope to bring this to Linux in the future but not for 0.10.

              Hardware Decode support via DXVA (Experimental - Windows Only)
              Decoding of some H.264, VC1 and WMV content via the GPU.
              Can provide a small improvement on slower hardware. Not suitable for fast CPU's

              Choice of Scalers
              Lanczos
              This is currently Handbrake's default scaler and will remain so.
              Bicubic (OpenCL) (Beta)
              Available on the Command Line (All Platforms) and Windows GUI. (Mac / Linux GUI's will come in a later release)
              Currently only available in OpenCL form so requires a AMD or Intel GPU supporting OpenCL 1.1 or later. Nvidia GPU's are not currently supported.
              When downscaling, up to 5% performance improvement can be achieved. No benefit when not downscaling.
              Small loss in quality over the Lanczos scaler.

              Denoise
              hqdn3d filter now accepts individual settings for both chroma channels (Cr, Cb)
              New NlMeans? denoiser. This is very slow, but results are significantly better than hqdn3d.

              Presets
              Added Windows Phone 8 Preset

              Updated Libraries
              x264 r2479-dd79a61
              Libav v10.1
              libbluray 0.5.0

              Libavformat is now used for muxing instead of mp4v2 and libmkv
              "Large File Size" checkbox has now bee removed for mp4, as the new muxer will transition to 64bit files automatically.
              mpeg2dec has also been replaced in favour of using libav

              The LibAV AAC encoder is now the default as FAAC has been removed.
              This encoder is adequate for most, but until it improves a bit further, we have enabled support for the FDK-AAC encoder also.
              This FDK option is a temporary measure until the LibAV encoder improves.
              Note that FDK-AAC is much slower and will likely bottleneck the encode process, but will produce better quality audio.

              H.265 encoder
              is now available through x265 1.4. While this encoder is still fairly new, we have seen some promising results come out of it. It's still under heavy active development and is only going to improve over time!

              Added VP8 Encoder (using libvpx)
              Available in MKV files only.

              Removed mcdeint deinterlace and decomb modes. This relied on the snow encoder in libav which has been was removed by upstream.

              Subtitle Improvements
              Burn in of SRT and Closed Captions is now supported. (Note, Requires XQuartz to be installed on OSX)

              Bug fixes and Misc Improvements

              Windows

              Accessibility / Usability Improvements
              Added option to 'Use System Colors'. The app should now be more usable in a High Contrast mode.
              Fixed Tab ordering to make the app more keyboard friendly.

              LibHB is now used for scanning instead of the CLI.
              Experiential Preview window is now available as a result. (Can be enabled via preferences)

              Improved the layout and design of the Audio and Subtitle tabs.
              Split buttons similar to the old 0.9.8 WinForms? GUI
              Improved layout on the track listbox to make better use of the space.

              Improvements to Auto-Naming feature.

              When Done
              Added an option that will reset this to 'Do nothing' when the app is closed and restarted.

              Presets
              New 'Presets' Menu
              Presets bar can now be hidden if it's not wanted.

              Numerous bug fixes
              Fixed the Issue in the source dropdown where the drive menu items did not work when clicked.
              Numerous fixes in the Picture settings panel around resolution calculation.
              Numerous fixes around the way Presets are loaded and saved, particularly around Picture settings.
              Removed Growl for Windows support due to bugs and issues with this library that remain unfixed. Project appears abandoned.
              Many misc other fixes.

              Windows XP is no longer supported. Windows Vista with Service Pack 2 or later is now a requirement.
              The 32bit build of the application is now considered deprecated. This is due to 32bit process memory limitations.

              Mac

              Build system updates to compiled under OS X 10.9
              Automatic audio and subtitle track selection behaviours which can be stored per preset.
              Improvements to Auto-Naming feature.
              Misc UI enhancements.
              Bug fixes

              Linux

              Automatic audio and subtitle track selection behaviours which can be stored per preset.
              Improvements to Auto-Naming feature.
              Batch Add to queue by list selection.
              Russian and Czech Translations
              Bug fixes and Misc Improvements
              Requires GTK3

              Command Line Interface

              Basic support for return codes from the CLI. (0 = No Error, 1 = Cancelled, 2 = Invalid Input, 3 = Initialization error, 4 = Unknown Error")
              Bug fixes and Misc Improvements

              Comment


              • #8
                Originally posted by Marc Driftmeyer View Post
                Those are scalers not encoders. It's useless if you're encoding raw/other 1080p to h264 1080p. Engineering teams from Nvidia, AMD and others have tried and failed to parallelise h264 encoding. x264 only uses it on lookahead and it requires OpenCL 1.2. There's only one lib that I have found that worked on Nvidia/AMD/Intel GPUs that requires OpenCL 1.1 and it's mainconcept's old proprietary h264 encoder. Last time I used it was on my Geforce 9600 in 2010 it worked pretty well by standards of that time. I only evaluated it for a project. Never used it for anything officially. I think Bandicam still uses mainconcept's lib today (don't quote me on that though).

                H265 is designed with parallelisation in mind, but is optimised for resolution > 1080p. I don't know about VP8/9 did not find any OpenCL encoders for those when I researched it in 2010-2012.

                I would also like to know if/when software will start using OpenCL 2.0.

                Comment


                • #9
                  Originally posted by Jabberwocky View Post
                  H265 is designed with parallelisation in mind
                  Do you have any source for this? I never heard someone talking about the possibility of GPU accelerated H265.
                  ## VGA ##
                  AMD: X1950XTX, HD3870, HD5870
                  Intel: GMA45, HD3000 (Core i5 2500K)

                  Comment

                  Working...
                  X