I've just tried this driver, the issue seems to be fixed now.
AMD Catalyst OpenGL 4.3 Graphics Driver, 7 new OpenGL Extensions - 3D Tech News and Pixel Hacking - ...
A couple of things:
-in the compute shader layout(location=...) is needed to specify an image2D binding point (glBindImageTexture), and not layout(binding=...)
-it seems like the memory barrier is not needed at all after the compute shader call (so the driver is properly figuring it out, maybe?). I suppose if I wanted to run another compute shader that writes the same memory, then I'd have to place barriers.
Thank you for fixing this!
That's strange, the spec explicitly says to use "binding" and not "location" in 188.8.131.52 (which points to 4.4.5).
Also, GL_ARB_shader_image_load_store specification tells:
- Data written to image variables in one rendering pass and read by the
shader in a later pass need not use coherent variables or
memoryBarrier(). Calling MemoryBarrier() with the
SHADER_IMAGE_ACCESS_BARRIER_BIT set in <barriers> between passes is
As I understand it, if you continue using UAVs then you must call MemoryBarrier, if you're accessing the data in a different manner then you don't need to sync.
Please correct me if I'm wrong.
Well I used imagestore in the compute pass, but a simple texture() in the displaying pass, so I guess no barriers are required, but I'll try if it crashes with imageload.
As for the binding vs location, the driver seems really beta/alpha version so anything is possible. Hopefully the new khronos conformance tests will eliminate these, but that will be only gl4.4+
I tried it out on NVIDIA hardware (imagestore and a texture sample afterwards) and it worked without the barrier. But be warned, it's different hardware and in my pipeline there are multiple stages, so it takes a little time between the compute stage and the draw stage. By "little" I mean something like 2-3ms.