<p>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. </p>

<p>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 <a href="https://software.intel.com/en-us/articles/opencl-and-opengl-interoperability-tutorial">https://software.intel.com/en-us/articles/opencl-and-opengl-interoperability-tutorial</a>). This allows you to efficiently integrate compute <em>passes</em> within your renderer, but it is not integrated into the rendering <em>pipeline</em></p>

CC BY-SA 3.0
2016-07-28T14:22:01.777Z
2016-07-28T14:22:01.777Z
GroverManheim
<p>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.</p>

<p>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</p>

CC BY-SA 3.0
2016-07-28T06:39:57.177Z
Why you want to use GPGPU for drawing million cubes in first place?
Derag
CC BY-SA 3.0
2016-07-28T10:20:26.327Z
Compute shaders are used for compute workloads, not rendering.

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
CC BY-SA 3.0
2016-07-28T13:44:09.133Z
@Derag Just trying to feed my cube fetish as fast as possible
FrickeFresh
CC BY-SA 3.0
2016-08-05T17:53:23.497Z
If you want to draw a million cubes, use ray-marching :)
russ
<compute-shader><opencl><cuda>
Compute Shader vs CUDA/OpenCL
FrickeFresh
# Compute Shader vs CUDA/OpenCL

(Asked by: username_0 on 2016-07-28)

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

**Tags:** compute-shader, opencl, cuda

> **Comments:**
> **username_1**: Why you want to use GPGPU for drawing million cubes in first place?  
> **username_2**: Compute shaders are used for compute workloads, not rendering.  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).  
> **username_0**: @username_1 Just trying to feed my cube fetish as fast as possible  
> **username_3**: If you want to draw a million cubes, use ray-marching :)  

---

## 1 answers

### Answer by username_4 on 2016-07-28. Score: 7

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*


---

