So I just recently learned about the Compute Shader and it looks from what I have picked up the same idea as parallel programming you would do with CUDA or OpenCL, but in the shader pipeline.
If I want to draw a million cubes in a scene should I be using one method over the other or both. If both how do you split that up so the GPU isn't trying to parallel compute both the shader and another process at the same time
It's not quite correct, today, to think of compute shaders as being "in the shader pipeline" in the same sense that your vertex and fragment shaders are literally hooked up into a pipeline. Compute shaders are not "hooked up" to anything currently, cannot drive rasterization, or directly consume the outputs of rasterization.
What it allows you to do, though, is consume and produce memory resources also used by draw calls in a relatively efficient way. OpenCL makes this rather difficult (see for example https://software.intel.com/en-us/articles/opencl-and-opengl-interoperability-tutorial). This allows you to efficiently integrate compute passes within your renderer, but it is not integrated into the rendering pipeline
The rule of thumb is that if you need rasterization (i.e. processing of triangulated geometry into pixels), you should be using the rendering pipeline; if you simply need to process a large piece of data, you should be using compute.
I'm also interested in sound arguments for and against compute shaders and CUDA/OpenCL (with graphics API interop). One that I've heard of is better queueing of compute workloads with the compute-specific API, but I'd like to know more (i.e. how does async compute come into the picture).
– IneQuation Jul 28 '16 at 10:20