1 Reply Latest reply on Aug 20, 2014 4:31 AM by dipak

    Extension for parallel primitives

    Ziple

      Hi everyone,

       

      Since the begining of OpenCL AMD has tried to make it easier to develop with OpenCL by providing tools and SDKs. I am thankful to you for that.

       

      As I have seen during my different projects with OpenCL, we always need some primitives to make parrallel scans, to sort data, or to make FFTs for example. Lots of people spend time writing their own implementations or trying to find the best available library for that (clMath, clFFT are good ones by the way).

       

      This has different disadvantages both for the end developpers like me, and for OpenCL implementers like AMD:

      - the end developpers need to ship the different libraries, keep them updated, test it on each platform to be sure it will compile and run ok, etc: that's yet another dependancy;

      - for OpenCL implementers, you are not sure that the end developper will write optimal (or building) code. Maybe the end developper will make stupid things. Moreover, providing parallel primitives from OpenCL functions pointers would let you to write optimal code for your products. (for example writing parallel scans using simd shared registers or so, which I am not sure it is possible currently with OpenCL)

       

      From an end developer point of view, we would like to have access to parrallel primitives from OpenCL just like with D3DCSX (for DirectCompute).

       

      Please consider my request for extension,

      Sincerely,

       

      Damien.

        • Re: Extension for parallel primitives
          dipak

          Hi Damien,

          Thanks for your suggestion. We do understand the usefulness of parallel primitives. As OpenCL becomes more and more popular, hope that many parallel primitives and basic algorithms (e.g. clMath) may be included dev package in future. In fact few parallel primitives may be included of OpenCL core as built-in functions. For example, OpenCL 2.0 already has "scan" as built-in work-group level function. So, I think OpenCL community is also thinking in the same direction.

           

          Regards,