Implementing algorithms via compute shaders vs. pipeline shaders

Question

With the availability of compute shaders for both DirectX and OpenGL it's now possible to implement many algorithms without going through the rasterization pipeline and instead use general purpose computing on the GPU to solve the problem.

For some algorithms this seems to become the intuitive canonical solution because they're inherently not rasterization based, and rasterization-based shaders seemed to be a workaround to harness GPU power (simple example: creating a noise texture. No quad needs to be rasterized here).

Given an algorithm that can be implemented both ways, are there general (potential) performance benefits over using compute shaders vs. going the normal route? Are there drawbacks that we should watch out for (for example, is there some kind of unusual overhead to switching from/to compute shaders at runtime)?

Are there perhaps other benefits or drawbacks to consider when choosing between the two?

Answer 1

There is no right answer if you are going to directly benefit from the compute shadrs/ GPGPU appraoch, this is highly dependent on the type of algorithm you are implementing, compute shaders and CUDA/OpenCL are a more generalized approach to overcome some of the limitations of that old shading languages hack. the most important benefits you will get:

• Accessing spatial info. in the old GLSL hack (well, it was a hack!) only gives little info about neighbor fragments since it uses texture coordinates. In compute shaders/CUDA/OpenCL accessing spatial info is much more flexible, you are now able implement algorithms like Histogram equalization on the GPU with un-ordered texture/buffer access.
• Gives you thread synchronization and atomics.
• Compute Space: the old GLSL hack will hard-wire the vertex/fragment compute space to your shader. Fragment shader will run with the number of fragments, vertex shader will run with the number of vertices. In compute shader you define your own space.
• Scalability: your compute shader/CUDA/OpenCL can scale up to the number of GPU SMs ( Streaming Multiprocessor) available unlike your old GLSL shader that should be executed on the same SM. (Based on Nathan Reed comments he says that's not true, and shaders should scale up as good as compute shaders should. I am still not sure though I need to check the documentation).
• Context switching: There should be some context switching, but I would say that depends on the application so your best bet is to profile your application.

Well in my opinion, if you want to go the compute shaders route, even though certain algorithms may be more suitable, there are certain considerations you need to take into account:

1. Hardware and backward compatibility. Compute shaders are only available in newer hardware and if you are going for a commercial product (e.g. game) you need to expect that a lot of users may not be able to run your product.
2. You usually need extra knowledge in GPU/CPU architecture, parallel programming and multithreading(e.g. memory sharing, memory coherency, thread synchronization, atomics and it's effect on performance) that you usually don't need using normal shaders rounte.
3. Learning resources, from experience there are far less learning resource for Compute shadrs, OpenCL and CUDA (which also offer OpenGL interoperability) than the usual shaders route.
4. Debugging tools, with the lack of proper debugging, tools development can become much harder than most shaders, at least shaders can be debugged visually.
5. I expect compute shaders to give better performance than the same algorithm in other shaders; if they were done right taking into consideration things from point 2, since they were designed to avoid the extra steps for graphics rendering. But I don't have any concrete evidence to support my claim.
6. You should also consider CUUDA/OpenCL for GPGPU if you are going that route.

Never the less I am sure it's great for the future, and will be great learning experience. Good Luck!