Repository navigation
glTexImage behavior when LOD higher than expected by dimensions #71
Description
Hi,
I'm looking into issue when 'glTexImage' functions are called with 'level' param higher we expect based on LOD0 texture size, and problems consequent from it.
GL 4.6 spec '8.14.3 Mipmapping' defines:
1)each LOD has a resolution lower than the previous one,
2)there is X LODs in a mipmap, where X=floor(log2(max(width, height, depth)))+1
In case of 'glTexStorage' functions, GL_INVALID_OPERATION error is required by spec in case LODs number is higher than calculated value based on dimensions. And result of 'glTexStorage' is a set of immutable LODs.
I understand that 'glTexImage' is more flexible tool, which can be called with any LODs order and size, since they're all mutable.
So I assume that we can not require any GL_INVALID_VALUE/GL_INVALID_OPERATION for 'level' param other than already specified. Is that right?
My main question is: when having inconsistent LODs set in texture(specifically smallest LOD 1x1px duplicated multiple times),
- what data we should expect in texture levels?
- what behavior to expect when using other functions on this data (glCopyImageSubData, glGetTexImage, etc)?
Example: to create a 32x32px texture, we put our data into all 6 expected mip-levels by 'glTexImage2D', and 1 time more unexpected.
Now we have texture with following levels LOD0:32x32, LOD1:16x16, LOD2:8x8, LOD3:4x4, LOD4:2x2, LOD5:1x1, LOD6:1x1.
From the moment we call 'glTexImage2D' on LOD6, all behavior gets basically unexpected. We got garbage data in either LOD6 or LODs 1-5. Depends on driver, dimensions 1D/2D/3D and order we call it 0->6 or 6->0.
Activity
pdaniell-nv commentedon Jul 7, 2020
It sounds like when a texture is specified in this way it will not be "texture complete" or "mipmap complete" as defined in section 8.17 "Texture Completeness" of the OpenGL 4.6 spec (https://www.khronos.org/registry/OpenGL/specs/gl/glspec46.core.pdf).
evgenKh commentedon Jul 9, 2020
Thanks for the reference!
But it looks like textures with more levels are still "complete", according to 8.17 "Texture Completeness":
( where q is basically a log2 of max LOD0 dimension)
Also most functions in question don't require texture or mipmap completeness.
glTexImage2D, glGetTexImage - don't, and only glCopyImageSubData does require it.
pdaniell-nv commentedon Jul 14, 2020
You may be hitting a not well specified corner of the specification when specifying an LOD outside of the expected mipmap chain. There probably is no expectation that LOD0-5 data remains well defined when the unexpected LOD6 is defined. I assume after specifying the unexpected LOD6 that if you go back and specify LOD0-5 consistent with LOD6 that the mipmap chain is unbroken and the data is correct?
evgenKh commentedon Jul 17, 2020
Hi. Yes in the case you specified(going back to other levels after specifying unexpected LOD6), mipmap chain is really unbroken again and data is correct.
This looks to me like normal usage of glTexImage when replacing entire texture with new texture of different resolution.
But we're investigating the case which is initially described and which is under-specified.
pdaniell-nv commentedon Jul 17, 2020
I agree this appears to be under specified, and ideally there would be a spec fix to clarify the behavior. Even with this spec fix, you'll likely continue to encounter implementations with different behavior. Are you able to modify your OpenGL usage to avoid this under specified behavior? I ask because I don't want you to be blocked on this issue, and hope an application-side work around is satisfactory for the short term.
werman commentedon Jul 17, 2020
It's something that came up when we wrote a test for Mesa in Piglit, so there is no application we know which has such behaviour.