750564 - NV GL driver fails when level >0 mipmaps aren't sized correctly based on level 0 dimensions

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect)

Description

[Kelsey Gilbert [:jgilbert]]

Relevant test: textures/texture-mips.html

This is theoretically workaroundable by reuploading or crossloading lower levels into a new texture, but this isn't exactly trivial.

Reading the GL spec, I wonder whether this test is valid. From the GL 3.0 spec, one prerequisite for texture completeness:
"The dimensions of the arrays follow the sequence described in the Mipmapping
discussion of section 3.9.7."

That is, each dimension should be max(1, floor(prev-dim/2)).
It appears that if this is not the case (which is one of our tests in texture-mips), the texture should be incomplete, which means:
"...if the texture image bound to the enabled texture target is not complete, then it is as if texture mapping were disabled for that texture unit."

If this is what it sounds like, we have a malformed test. I don't think this is something we can reliably workaround, either, if we wanted WebGL to allow this. (Given the wording of the spec)

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

I think that you should discuss this on the public-webgl list asap, if you think there may be a malformed test. I don't have time right now and you might get a reply there before I do.

Comment 2

[Kelsey Gilbert [:jgilbert]]

Looking at this again, it seems like this alone is not a problem, since the failing tests do not rely on renderings of mipmap-incomplete textures.

Basically, the problem is persisting higher-level mipmaps through level-0 resizes. One effect of this is that you can't set mipmaps highest-level-first. I can't seem to find anything relevant in the spec for this, though.

Interestingly, under "Effects of Completeness on Texture Image Specification":
"An implementation may allow a texture image array of level 1 or greater to be created only if a mipmap complete set of image arrays consistent with the requested array can be supported. A mipmap complete set of arrays is equivalent to a complete set of arrays where levelbase = 0 and levelmax = 1000, and where, excluding borders, the dimensions of the image array being created are understood to be half the corresponding dimensions of the next lower numbered array (rounded down to the next integer if fractional)."

This seemed relevant at first, but now seems to only indicate that, say, if we attempt to set level 32 to a 1x1 texture, the implementation can refuse, since it can't support the corresponding 2^32 x 2^32 texture for level 0.

Comment 3

[Kelsey Gilbert [:jgilbert]]

It may be best to bring this up in the WebGL conference call this week.

Mipmap stuff is confusing, but I think it's possible for us to make them less-so for WebGL. If we require that users specify mipmaps in order lowest-to-highest, this would reflect the common and well-supported usage pattern.

We could also assure that mipmaps always succeed, by rejecting badly-sized >0 levels, and clamp the texture's TEXTURE_BASE_LEVEL and TEXTURE_MAX_LEVEL to cover only the valid mipmaps.

Assuring that mipmaps are always well-formed means we never have the case of the texture unit having to disable itself, which can leave users wondering why their carefully (albeit incorrectly) specified texture is failing to render at all.

Comment 4

[Kelsey Gilbert [:jgilbert]]

This is fixed in newer drivers.