CODEWITHSUNDEEP
openglcompute-shader
Armen Avetisyan
Armen Avetisyan

Reputation: 1258

How fast is glDispatchCompute?

Official OpenGL wiki says

Compute shaders are not part of the regular rendering pipeline. So when executing a Drawing Command, the compute shader linked into the current program or pipeline is not involved.

So I expect it to invoke faster than glDrawArrays. Can anyone provide more details about the overhead?

Is glDispatchComputeIndirect​ the faster alternative because it skips error-checks?

Upvotes: 1

Views: 2289

Answers (2)

dv1729
dv1729

Reputation: 1057

Can anyone provide more details about the overhead?

glDrawArrays overhead is small when you draw enough primitives for each call to it, this is true for all drawing commands: less draw calls = more performance.

Is glDispatchComputeIndirect​ the faster alternative because it skips error-checks?

No, as Nicol Bolas said, you don't usually use a compute shader when you need a vertex-fragment shader, although there are situation whens this is not so clear.

glDrawArraysIndirect exists. This function is similar to glDrawArrays but takes the rendering command information from a buffer on the GPU. This is very useful if the rendering command information is generated on the GPU, to avoid reading it (avoiding expensive GPU to CPU copy). However, this is a special case.

glDrawArrays overhead will be big when you call it with a low primitive count. Avoid this situation by grouping multiple objects and meshes. glMultiDrawArrays can be useful​ then: https://www.khronos.org/opengl/wiki/Vertex_Rendering#Multi-Draw

Upvotes: 1

Nicol Bolas
Nicol Bolas

Reputation: 473447

The question is essentially irrelevant.

Compute shaders are for computing data. The rendering pipeline is for rendering stuff. You don't use one for a task where you need the other.

If you're trying to build indirect rendering commands, why would you go through the effort of making such computations look like a drawing operation instead of just making a simple CS? And if you're trying to actually draw stuff, a compute operation wouldn't have access to most of the stuff that makes rendering fast in 90% of cases.

So it doesn't matter if one is faster or slower than the other, because you wouldn't use one for the same tasks as the other. And since they do two completely different things, there's no way to gauge the performance of one relative to the other.

It's like asking whether sin is faster than sqrt. It doesn't really matter, because you cannot replace one with the other. If you need a sin, sqrt isn't going to help. And vice-versa.

it skips error-checks?

Who says it "skips error-checks"?

Dispatch operations still have to make sure that any textures/images/buffers which the CS needs are actually bound and are appropriate for the CS.

Upvotes: 0

Related Questions