OpenGL: Wrong zoom level with texture generated via glTextureView()
Froyok opened this issue · comments
Description
In my RenderDoc captures of my OpenGL program, several textures represented via a TextureView result in an incorrect zoom level when using the Texture Viewer. The "1:1" and "Fit" don't produce the correct zoom level. The nearest/bilinear filter also seems to trigger incorrectly.
For example, with a texture of 15x8 pixels it will fill the window when using the 1:1 button and the Fit button will result in extreme zoom levels (like >6000%). This doesn't happen with texture created in other ways.
I would expect the zoom levels and buttons to behave like it would with other textures/render targets.
Example of a 40x22 texture in "fit" mode:
Example of a 40x22 pixels texture in "1:1" mode:
To give some context on what is done in the background: those texture views are actually different mip levels of the same source texture. I do that to be able to downsample from one mip into another smaller one using a custom shader rather than using a traditional bilinear filter.
Steps to reproduce
- Download the following capture: rdc_bug_report_textureviews_zoom.zip
- Open the Event Browser window
- Expand to:
a. Frame
b. Draw view
c. Post-Process
d. Fog blur
e. Blur downsample
f. Downsample 6
g. glDrawArrays() - Use the Fit or 1:1 buttons in the TextureViewer on the Inputs or Outputs texture.
(I hope this is enough, I tried to make the capture as lightweight as possible.)
Environment
- RenderDoc version: 1.30 (built from: 3eccdc7)
- Operating System: Linux Manjaro (Arch based)
- Graphics API: OpenGL 4.6 (Compatibility Profile) Mesa 23.1.9-manjaro1.1
- Mesa version: 23.1.9
- GPU: AMD Radeon RX 7900 XT (gfx1100, LLVM 16.0.6, DRM 3.54, 6.6.8-2-MANJARO)
- OpenGL driver: Gallium (?) (aka not Zink)
Thank you for such a clear reproduction case. Other places were incorrect i.e. saving the texture contents. The issue was glTextureView with non-zero minlevel.