For my setup (Nvidia RTX 2070, driver v537.42, Windows 10 19045.3448), there is a bug in one of the compute tests. Specifically, "Cubemap non-layered Image View", which is almost identical to the "3D non-layered Image View" test above it which doesn't display this behavior.
Normally before calling the second compute shader you'd use glMemoryBarrier(GL_SHADER_IMAGE_ACCESS_BARRIER_BIT), a.k.a. gl_catch_up_before(MemoryActions.texture_simple_views), to make sure it can see the results of the first shader. However, if you do that then the values read from after the second compute shader appear to match the output of the first compute shader, as if the second one had no effect. But if I instead use GL_TEXTURE_UPDATE_BARRIER_BIT, a.k.a. MemoryActions.GL_TEXTURE_UPDATE_BARRIER_BIT, it works as expected.
Again, this behavior doesn't happen with the 3D texture version of the test, so I'm inclined to believe it's a driver bug.
For my setup (Nvidia RTX 2070, driver v537.42, Windows 10 19045.3448), there is a bug in one of the compute tests. Specifically, "Cubemap non-layered Image View", which is almost identical to the "3D non-layered Image View" test above it which doesn't display this behavior.
Normally before calling the second compute shader you'd use
glMemoryBarrier(GL_SHADER_IMAGE_ACCESS_BARRIER_BIT), a.k.a.gl_catch_up_before(MemoryActions.texture_simple_views), to make sure it can see the results of the first shader. However, if you do that then the values read from after the second compute shader appear to match the output of the first compute shader, as if the second one had no effect. But if I instead useGL_TEXTURE_UPDATE_BARRIER_BIT, a.k.a.MemoryActions.GL_TEXTURE_UPDATE_BARRIER_BIT, it works as expected.Again, this behavior doesn't happen with the 3D texture version of the test, so I'm inclined to believe it's a driver bug.