If I write to an image with imageStore in a compute shader, can I immediately call texture() to sample a texture sampler using that image, and expect to get the written value, within the same compute shader? Or is a memory barrier and separate passes required?
You can’t. While SPIR-V’s image memory semantics may cover access to sampled images (depending on how you read its docs), GLSL’s memoryBarrierImage only applies to images, not textures. So if you’re not using a shading language that gives access to all of SPIR-V’s barriers (and again, this requires a specific reading of OpTypeImage as including sampled images. I don’t know if I buy that reading myself), you cannot synchronize properly.
Also, why would you want to?
If a shader invocation just wrote a value, that means… it knows what that value is. Why should it need to read it? And if it were some other invocation that wrote it, then you need inter-thread syncing anyway to read it. So you may as well just communicate that value directly.
I’m doing GI with voxels. The downsampling code uses imageStore() to write image data, but the GI step relies on trilinear volume texture samples, because using the hardware for that is MUCH faster than rolling your own sampler in GLSL.
Do I need to process these in separate passes? Is a memory barrier required in between passes?
Since you’re relying on interpolation, and therefore are reading from values written by other invocations, invocations which may not even be in your work group… yes.
You are reading memory written by a previous operation. Why wouldn’t that require synchronization including a memory barrier?
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.