I was trying to understand sequential execution of compute shaders. Suppose I have compute shaders computeA and computeB: computeA writes on an SSBO and computeB reads from it. In OpenGL one usually issues a
glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT)
after the dispatch call of computeA (i.e. the execute call in openrndr), since one is not guaranteed syncronicity. As far as I can see from the source code, the .execute call does not incorporate such a barrier, and it makes sense. My experiments seem also to confirm that. Is there a way to invoke such a command without directly passing from a low-level OpenGL library?
Interesting! I have been using 8 or 9 compute shaders sequentially in a program. Some are reading, writing or doing both from SSBOs. Do you think they may be misbehaving? I haven’t noticed… maybe that’s what makes the result interesting? XD I’ll ask in Slack.
Technically different dispatch call are not assured to be synchronous. A nice example is here, in particular
Before accessing the image data after the compute shader execution we need to define a barrier to make sure the data writing is completly finished. The glMemoryBarrier defines such a barrier which orders memory transactions. The GLbitfield parameter barriers specifies the barriers to insert. They must be a bit wise combination of any GL barrier_bit constants (see: glMemoryBarrier - Khronos). In this case, we only need the GL_SHADER_IMAGE_ACCESS_BARRIER_BIT which assures access using the image functions will reflect data written by shaders prior to the barrier.
This is for images, but you have barrier for all types.
As for providing interesting effects, I am all up for it! Actually I’ll probably show one of these artifacts tomorrow at the meeting
