Texture Viewer cannot distinguish image binding from same texture but in different mipmap level
JHex-git opened this issue · comments
Description
For two image binding from same texture but in different mipmap level used in one compute shader dispatch, the Texture Viewer cannot distinguish them. To be more specific, a texture in output in Texture Viewer can be viewed when clicked on it. But if we have two image from same texture but different mipmap level, when you click to image A, Texture Viewer will switch to view image A. But after that, when you click image B, Texture Viewer will not switch. It seems that it considers B to be just A. What makes this more convincing is that if you click another texture C, then you can click image B and the Texture Viewer will switch to view B.
Steps to reproduce
Here is how I bind texture image. I'm not sure whether read/write matters.
glBindImageTexture(0, example_texture, 0, GL_FALSE, 0, GL_READ_ONLY, GL_R8)
glBindImageTexture(1, example_texture, 1, GL_FALSE, 0, GL_WRITE_ONLY, GL_R8)And here is how I use image in compute shader.
layout(binding = 0, r8) uniform image2D uExampleImage0;
layout(binding = 1, r8) uniform image2D uExampleImage1;Environment
- RenderDoc version: 1.32
- Operating System: Windows10
- Graphics API: Opengl 430 core
I'm not sure I understand exactly what the problem is here. You say that the texture viewer "can't distinguish" between the textures, but you're also saying that the exact same texture is bound in both slots so there is nothing to distinguish them and the same texture is bound in both?
Do you mean that when switching between two different binds that have the same texture with different mip ranges then the selected mip doesn't change? If so then that is deliberate behaviour and not something I'd consider a bug. I appreciate that in this case it is unusual but I don't think I want to add specific special-case logic to behave differently here. You can always select which mip you are viewing without changing binding.
Sorry for failing to state the problem clearly. I mean that in the code I provide above, uExampleImage0 and uExampleImage1 are from same texture, but not same mip level. Say uExampleImage0 is in mip level 0 and uExampleImage1 is in mip level 1. And when I want to view uExampleImage0, I should click it in output in Texture Viewer. And this works. However, after I click uExampleImage0, when I click uExampleImage1, the Texture Viewer will not view uExampleImage1, but still keeps viewing uExampleImage0. Instead, I have to click some texture else first and then I can click uExampleImage1 so that the Texture Viewer will show content of uExampleImage1.
It is neither the case of changing binding nor mip range. I mean different mip level of a texture actually.
Okay, I think have got across what you mean. But I think it is a little bit strange that when you click to one image directly, Texture Viewer will view the exact mip level but when you switch between two images of same texture but in different level, the mip level will just not change in Texture Viewer.
Just to clarify, you are talking about changing between two bindings of the same texture at two mip ranges. It's important to remember that uExampleImage0 and uExampleImage1 are two names for the same texture and not two different textures entirely.
As I say the behaviour here is deliberate, and while I do agree it is a bit odd for this unusual situation I believe it makes more sense than trying to guess whether the user wants to have the mip level changed from under them or not when viewing the same texture. Normally when viewing the same texture we make every effort to preserve the view the user has, which is usually better than changing settings out - just in this case that's something you deliberately want to do. The reason it behaves differently when switching from another viewed texture is there is nothing to preserve, so we select the most appropriate mip level at that point.
From the comment above, if the only difference between the bindings is the mip level you can select that directly from the mip selection rather than indirectly from the binding.