--- Quote Start ---
However, a simple regular opencl channel should be able to to the same thing, I don't see there is any reason
using this design.
--- Quote End ---
If you need a shared buffer that is too big to fit on-chip, you can use this design because here, the shared buffer is stored in global memory. If, however, you can get the job done with a small buffer and the latency between the writes from producer and reads from consumer is small, then a standard on-chip channel can do the job just fine.
--- Quote Start ---
1) Is there a way to do on-chip communication between two kernels using OpenCL when the amount of data communication
is not determined at compilation time. You may take the simple filter as an example. Kernel 0 filters input data streams and extracts the data
that is larger than 10. Kernel 1 gets the output data of Kernel 1 and does some processing.
--- Quote End ---
Yes, you can use non-blocking channels. These channels provide a flag using which you can determine if the non-blocking read/write has been successful or not. You can wrap your channel operation in a while(1) loop and use the flag, or even the data received from channel, to break out of the loop. You can find multiple basic examples in Altera's documents.
--- Quote Start ---
2) Will the producer, consumer and manager scheme work for the filter example? If not, when will it be used to replace
the basic on-chip channel based design?
--- Quote End ---
Similar to above, you can also use non-blocking channels with this type of design where the shared buffer is in global memory.
Honored Contributor
