2 Replies Latest reply on Nov 17, 2014 7:00 AM by dipak

    OpenCL™ 2.0 Demystified – Pipes

    pinform

      In your responses to the first blog post in the OpenCL 2.0 Demystified series, you expressed a subtle but important quality that SVM brings to your applications: simplicity.     

       

      We hear you.  Simpler code indicates elegance in application design. 

       

      Our next blog post explains how pipes in OpenCL 2.0 can make your code simpler and more readable.  As usual, we have insights, code snippets, and complete samples that you can download.

       

      All these links are available directly in the blog.  Make sure you have supported hardware (there’s a complete list on the driver download page).

       

      Play with the examples.  Maybe write your own OpenCL 2.0 pipe.  And share your observations with the community here.  With an understanding of pipes, you will move one step closer to understanding the full potential of OpenCL 2.0.

        • Re: OpenCL™ 2.0 Demystified – Pipes
          coordz

          It would have been nice to include some description in the blog post as to why you would use work_group_reserve_read_pipe rather than just letting each work item do a read_pipe() without a reservation id. Performance?

            • Re: OpenCL™ 2.0 Demystified – Pipes
              dipak

              Thanks for your suggestion. I've already forwarded to concern person.

              I want to highlight few important points of reservation mechanism as follows:

               

              As per OpenCL Spec:

              "NOTE: The read_pipe and write_pipe functions that take a reservation ID as an argument can be used to read from or write to a packet index. These built-ins can be used to read from or write to a packet index one or multiple times. If a packet index that is reserved for writing is not written to using the write_pipe function, the contents of that packet in the pipe are undefined. commit_read_pipe and work_group_commit_read_pipe remove the entries reserved for reading from the pipe. commit_write_pipe and work_group_commit_write_pipe ensures that the entries reserved for writing are all added in-order as one contiguous set of packets to the pipe.


               

              • If multiple work-items in a work group need to access a pipe item multiple times, this procedure is clearly beneficial.
              • As work-group level reservations put the items in order within the work-group and so it gives better cache benefits. Performance would be better.
              • As reading/writing to/from a reserve space needs an index to access the item, the reserved space can be thought as array/buffer and any scatter/gather operation can be performed using the index.
              • In a typical scenario where a WI  working with multiple data items and wants to pass them such that corresponding consumer WI can access them as a in-order contiguous set, this is very useful to achieve the goal.

               

              Regards,