I've been looking at Interface queries in order to prevent common mistakes that are time consuming to debug, such as forgetting to bind a buffer, binding the wrong resource type, etc.

However, I wasn't able to find what I wanted for images. I'd like to make sure that the type of the texture, the memory qualifier and the texture format are the same in the c++ code and in the shader :

glBindImageTexture(index, texture, 0, true, 0, GL_READ_ONLY, GL_RGBA32F);

layout(binding = 0, rgba32f) uniform writeonly iimage2D _heightmap;

Using glGetProgramResourceiv with GL_UNIFORM and GL_TYPE, I was able to get the type of the image, iimage2D. But nothing for the memory qualifier and the image format.

Is there a way to do that, other than parsing the shader?


1 Answer 1


Those are not accessible via introspection. It should also be pointed out that some of them don't have to "match".

The shader-defined format doesn't have to be the same as the image-bound format. The image-bound format defines how writing from the image interprets the data provided by the shader. The shader-defined format determines how reading from the image interprets the data in the image. So the two values are fundamentally doing different things and need not match either each other or the texture's internal format. There are rules for how conversion works between these and the image's actual format.

For the access type, you could just pass GL_READ_WRITE for everything and let the shader decide how it's going to access the storage. Given that Vulkan has no equivalent to this value, it probably doesn't matter performance-wise. Also, note that the multibind function glBindImageTextures, which binds multiple images in one call, always uses GL_READ_WRITE (and doesn't have a specified format). Since the whole point of that function is performance, it almost certainly doesn't matter if you always use read-write from the binding side.

  • $\begingroup$ I see, too bad. I was aware about the formats, however given that most of the time I use images the format is the same as the original one, I wanted to eliminate the chance of using a wrong format in the shader, and for the few times I'd need to use a different format, I'd use a view and compare the shader format with the view, ensuring I always have the good format set. However I wasn't aware that the access type could be different, so at least that's one less thing I have to worry about! $\endgroup$
    – Aulaulz
    Jul 26, 2020 at 22:15
  • $\begingroup$ Side question, does Vulkan also requires to specify the type of the image API side, or does it just assume that the view will have the correct format? $\endgroup$
    – Aulaulz
    Jul 26, 2020 at 22:19
  • 1
    $\begingroup$ @Aulaulz: The OpenGL image binding API predates the View Texture feature, so the image binding API needed a way to have the binding format be different from the texture's format. With view textures, there's really no point in it, since you could just create a new view with the desired format (which is why glBindImageTextures [note the "s"] does not allow you to specify the format). The two different specifiers use the same conversion rules. Since ImageViews are part of Vulkan's API from the beginning, there was no need for the redundant concept. $\endgroup$ Jul 26, 2020 at 22:44
  • $\begingroup$ Oh I wasn't aware of glBindImageTextures. I'll use that instead. All of that makes sense now, thanks! $\endgroup$
    – Aulaulz
    Jul 26, 2020 at 23:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.