Are there any limitations on simultaneous usage of fbo and shader_image_load_store extension?
The use case is following:
FBO with 4 color attachments is initialized
For the problematic rendering pass, the 0 and 3 color attachments are bound via glDrawBuffers call (1 and 2 are used in the previous passes, and associated textures are used for this pass as input)
These attachments are linked to the respective out variables via glBindFragDataLocationEXT calls
Image is created and then bound via glBindImageTextureEXT call
Shader works fine until if no imageStore instruction is called. If it is, then one of the color attachments is corrupted and consists 0 value.
Thanks a lot for every suggestion why that might happen.
Peter
I think your problem may be related with the one I describe here .
After some OpenGL-4.2-Core-Profile-Specs-reading, I found in Table 6.56 some “numbers” that may be usefull (all the values are relative to OpenGL 4.2 - Core Profile): MAX_IMAGE_UNITS, MAX_FRAGMENT_IMAGE_UNIFORMS, MAX_COMBINED_IMAGE_UNIFORMS, MAX_COMBINED_IMAGE_UNITS_AND_FRAGMENT_OUTPUT.
All these caps have the minimum value of 8 in OpenGL-4.2, which makes me think that your problem (and mine) are not related with these limitations.
One more curiosity, in “GPU Caps Viewer” my system reports to support “4.2.11318 Compatibility Profile/Debug Context”, but the values of MAX_FRAGMENT_IMAGE_UNIFORMS and MAX_COMBINED_IMAGE_UNIFORMS are reported to be 0.
Still, I’m able to use image uniforms. =P
I’m pretty sure you cannot write to the same texture image using framebuffer operations and image store at the same time. Even reading a texture currently bound as an attachment to the current framebuffer works only in limited cases.