biuDepthRange/biuDepthRange_001_to_002.html and gl_FragCoord/gl_FragCoord_001_to_003.html

[kenrussell]

Chris Green from Imagination has pointed out that the following tests introduced in the 1.0.2 conformance suite may have bugs:

conformance/ogles/GL/biuDepthRange/biuDepthRange_001_to_002.html
conformance/ogles/GL/gl_FragCoord/gl_FragCoord_001_to_003.html

See https://www.khronos.org/bugzilla/show_bug.cgi?id=840 .

[laneroberts]

The depth range values are set in ogles-utils.js (line 514ish) but it seems the uniforms aren't marked as used. The following does the trick, but I'm not familiar enough with the code to know if there's a less hacky way of doing it... Calling getUniformLocation() returns null for these but it marks them as "used" all the same. This patch is based on the current 1.0.3 codebase.

sdk/tests/conformance/ogles/ogles-utils.js:
@@ -461,3 +461,3 @@

• getUniformLocation("gl_DepthRange.diff");
• getUniformLocation("gl_DepthRange.far");
• getUniformLocation("gl_DepthRange.near");

[kenrussell]

Note that this test was imported from the OpenGL ES 2.0 test suite, so it is essential that a comparison be made to the original sources to understand what both the intended and desired behaviors are.

[laneroberts]

Does the ogles 2.0 test suite do any shader source processing? I would have thought that the error/failure is WebGL test-specific.

[michaeljgreen]

This WebGL conformance test fails, not because of anything to do with depth range, but with the check on the number of active uniforms done in drawWithProgram (ogles-utils.js). The depth range part of test looks the same as used for ESCTS-2.0.3.0-20091116, but as far as I can tell, the OGLES 2.0 GTF doesn't have an expectation on the number of uniforms.

Lane's change works because it 'touches' the built-in DepthRange uniforms - thus marking them as used, so the "Check for unset uniforms" doesn't fail. However, It looks like the script will allow additional "test specific uniforms" to passed in from the test .html source - is that possible?

[michaeljgreen]

Hello Ken, Do you know if anyone has taken a look into this? Thanks.

[kenrussell]

Sorry for the long delay replying to this issue.

It was actually already fixed in #340 . Please see https://www.khronos.org/bugzilla/show_bug.cgi?id=840 for more details.

The fix that was made is really just a workaround for bugs in the OpenGL ES conformance suite. I've filed #390 to track fixing this properly.

[michaeljgreen]

Thanks Ken, That would fix the 'known but not active' situation - but here we have 'active but not known. We're still seeing the test fail at the next ("Check for unset uniforms") section in ogles-utils.js.

The test's drawWithProgram function queries the ACTIVE_UNIFORMS, which we believe should include any built-in DepthRange uniforms. It then checks to see if every member of this active list was expected - by marking them as 'used'. The test's 'known' uniforms (gtf_ModelViewProjectionMatrix, viewportwidth, viewportheight) are looked for, then any test-specific values are checked for. (This is where, prior to the #340 change, a test-specific uniform that wasn't active would have failed.) The test then checks that the whole list was marked as 'used' and this is where we’re seeing the failure.

The change that Lane mentioned earlier basically added the DepthRange uniforms to this 'known' group, so this later check doesn't fail.

Is this is something that could be added to the test, or is the position that the ACTIVE_UNIFORMS count for WebGL should include the DepthRange values incorrect?

[bfulgham]

It's interesting to me that the test harness ogles-util.js is not internally consistent.

We run into problems because we retrieve an invalid location around line 440:

var location = gl.getUniformLocatoin(program, name);

and use this value even though it is null.

Later, around line 476, the test checks for a null return from gl.getUnformLocation and bypasses processing for this case.

If you simply add a null check at line 440, these tests then pass.

[kenrussell]

It would be really helpful if you could dig into this behavior, in particular comparing to the OpenGL ES conformance suite harness. The original author of ogles-utils.js has left the project, and I am swamped right now and can't devote the necessary time right now to examine the original harness, the WebGL harness, understand the motivation for the differences in behavior, and resolve them.

If you could supply pull requests fixing issues you see in the WebGL conformance suite that would be helpful.