Hello everyone,

I have a simple game prototype that uses OpenGL for rendering. I have been wanting to implement a postprocessing step as a compute shader, so I wrote a simple shader that writes pure white to every pixel in the image just as a test.
The problem I'm having is that the shader appears to do absolutely nothing, despite confirming with RenderDoc that it does execute, and that the image is bound correctly.

To breakdown the CPU-side code: render::main_scene() does the main geometry pass and renders into core_rt, an SRGBA/MSAA rendertarget. We blit this to ping_rt, an RGBA8/non-MSAA rendertarget, and the color attachment of this framebuffer is bound to the image sampler.
The compute shader is then dispatched with a workgroup count hardcoded to work with 1920x1080, just for now. glMemoryBarrier() is called so that the compute shader's work is visible when we do the remaining blits.

When it's all said and done, the final image is no different than if I were to comment out the call to glDispatchCompute(). Also, I have a RenderDoc capture of a frame in case that would help anyone help me.
One final note: I have tried enabling the GL debug context, but the only non-notification messages it gives me are performance warnings about vertex shaders being recompiled, no usage errors are generated.

I have been wrestling with this issue for days now, and across multiple forums, so please gamedev.net, you are my only hope,
-Nick

@JoeJ I can't find any results when I try to google for OpenGL execution barrier. I know that I should pick up the OpenGL superbible but I just don't have a copy yet.

I have also tried really hacky crap like inserting a sleep(1000) after the memory barrier. If my problem was synchronization, surely that would reveal it.

One thing I am going to try after work is creating a texture view (a thing I only learned about yesterday) into the core_rt color attachment, and then binding that to the image sampler. This way I should be able to use the SRGB image in the compute shader directly. If nothing else that will get rid of the superfluous blits that are bit-crushing my render lol.

@taby Thank you for that example. It at least confirmed for me that only a gl::MemoryBarrier is required; there's no execution barrier, but I still don't see steps that my program is missing.

@JoeJ The thing is, that's already what I was doing. I was attaching the GL name of the color attachment of the framebuffer (not the default framebuffer, one I've manually created), which is itself a texture, unless I'm misunderstanding something?

Ok everyone I was able to solve this problem, though I don't know exactly how what I did fixes the issue.

Instead of creating the postfx framebuffer's color attachment with glTexImage2D(), glTexStorage2D() is used instead so that a texture view (ping_linear_view) can be created into the texture. This is important because it's the only way to use an SRGB image in a compute shader. See https://www.khronos.org/opengl/wiki/Texture_Storage#Texture_views​ for more details, but basically I am able to “cast” a gl::SRGB8_ALPHA8 image into a gl::RGBA8 image for the purposes of compute shader reads/writes.

So there are two differences that I can see could have fixed the issue:

1. The image the compute shader is manipulating is now allocated with immutable storage instead of mutable storage
2. We aren't doing a bunch of blits back-and-forth before dispatching the compute shader

Now, the example that @taby shared shows a compute shader that manipulates an image allocated with mutable storage, so I'm leaning towards the second difference as being what fixed things, which is also what @joej hypothesized.

That's all I have to say about this. If anyone wants to add any insight or ideas that would be great, but this issue can be considered solved.

@Nickmav1337 I just realized that the old blits were happening after the shader not before, but same idea.