<p>Those are not accessible via introspection. It should also be pointed out that some of them don't <em>have</em> to &quot;match&quot;.</p>
<p>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 <a href="https://www.khronos.org/opengl/wiki/Image_Load_Store#Format_conversion" rel="nofollow noreferrer">rules for how conversion works between these and the image's actual format</a>.</p>
<p>For the access type, you could just pass <code>GL_READ_WRITE</code> 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 <code>glBindImageTextures</code>, which binds multiple images in one call, always uses <code>GL_READ_WRITE</code> (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.</p>

CC BY-SA 4.0
2020-07-26T22:15:39.520Z
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!
Aulaulz
CC BY-SA 4.0
2020-07-26T22:19:16.123Z
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?
Aulaulz
CC BY-SA 4.0
2020-07-26T22:44:55.477Z
@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.
Nicol Bolas
CC BY-SA 4.0
2020-07-26T23:05:23.173Z
Oh I wasn't aware of glBindImageTextures. I'll use that instead. All of that makes sense now, thanks!
Aulaulz
CC BY-SA 4.0
2020-07-26T14:07:38.043Z
2020-07-26T22:54:05.370Z
2020-07-26T22:54:05.370Z
Nicol Bolas
<p>I've been looking at <a href="https://www.khronos.org/opengl/wiki/Program_Introspection#Interface_query" rel="nofollow noreferrer">Interface queries</a> 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.</p>
<p>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 :</p>
<pre><code>glBindImageTexture(index, texture, 0, true, 0, GL_READ_ONLY, GL_RGBA32F);

layout(binding = 0, rgba32f) uniform writeonly iimage2D _heightmap;
</code></pre>
<p>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.</p>
<p>Is there a way to do that, other than parsing the shader?</p>

<opengl>
OpenGL shader introspection/interface queries for images
Aulaulz
# OpenGL shader introspection/interface queries for images

(Asked by: username_0 on 2020-07-26)

I've been looking at [Interface queries](https://www.khronos.org/opengl/wiki/Program_Introspection#Interface_query) 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?

**Tags:** opengl


---

## 1 answers

### Answer by username_1 on 2020-07-26. Score: 1 | Accepted answer

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](https://www.khronos.org/opengl/wiki/Image_Load_Store#Format_conversion).

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.

> **Comments:**
> **username_0**: 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!  
> **username_0**: 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?  
> **username_1**: @username_0: 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.  
> **username_0**: Oh I wasn't aware of glBindImageTextures. I'll use that instead. All of that makes sense now, thanks!  

---

