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.
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?
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.”