[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Problems with textures/texture-size-limit.html



On Fri, Aug 16, 2013 at 12:55 PM, Wong, Alex <waiw@quicinc.com> wrote:
>
> Hi all,
>
> Two problems with https://github.com/KhronosGroup/WebGL/blob/master/conformance-suites/1.0.2/conformance/textures/texture-size-limit.html
>
> 1) Incorrect Mipmap Level in Inner Test Loop
>
> The first problem I discovered was an incorrect calculation of the intended mipmap level in the innermost test loop. On line 138 of the test, the original reads:
>
>       var level = numLevels - l - 1;
>
> However, we see that earlier, on lines 133-134, that there is another value calculated, numTestLevels, that derives from the lesser of the calculated maximum possible mipmap level and the limit that's set for this particular test:
>
>     var numLevels = numLevelsFromSize(t.maxSize);
>     var numTestLevels = Math.min(numLevels, t.maxLevel);
>
> The t.maxLevel value comes from lines 71-91 of the tests, where specifics about each test case are defined. In the particular case of cubemap texture, the maximum mipmap level is meant to be limited to 5, not to the calculated maximum of 12. (The calculated maximum value is derived from the gl.MAX_CUBE_MAP_TEXTURE_SIZE using the numLevelsFromSize() function on line 47. Since our maximum cubemap texture size is 4096, the maximum mipmap level is 12.)
>
> Changing numLevels to numTestLevels on line 138 causes all the success cases to pass, and I believe is the intended test behavior.

After reading the test I'm afraid I don't agree. The comment at the
top of the loop on line 136 says "Do bottom levels first", so it seems
to me that the test was intended to allocate the bottom 5 mipmaps per
cube map face.

The test passes on Mac OS and Windows machines I've tested on. It also
passes on a Nexus 4 running Chrome 29.0.1547.59, and this device uses
a Qualcomm Adreno 320.

What is the failure mode you are seeing? It sounds to me like there is
a bug in the driver.


> 2) Incorrect Calculation for Invalid Texture Size
>
> Making the first modification caused the cubemap success cases to pass, but also caused the cubemap failure cases to fail, when they had previously been passing. I tracked this down to an incorrect calculation of the texture size required to cause gl.texImage2D() to fail at a given mipmap level.
>
> The test assumes that doubling the size of the texture will cause the allocation to fail, as shown on line 140:
>
>       var badSize = size * 2;
>
> This assumption is valid if we always start our testing with the maximum possible mipmap level (12 in our case). But since the test is changed to respect the maximum mipmap level specified in the test configuration (5 for cubemap textures), doubling the size at the given mipmap level no longer results in an invalid texture, since it would not necessarily expand level 0 beyond the texture size limit. The proper calculation to force level 0 to exceed the texture size limit is:
>
>       var badSize = 1 << (numLevels - level);
>
> This ensures that the gl.texImage2D() calls that are meant to fail do, and I believe correctly expresses the intent of the test.

Given the analysis in (1), this change doesn't apply.

-Ken


> Thanks
> Alex
>
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------