[Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers

[Benoit Jacob]

Here's an update on the status of these failures. Scroll down to the part about program-test.html for the real news.

> i965 driver:
> 
> Results: (8866 of 8879 passed)
> 
> > Failures:
> > conformance/context/context-attributes-alpha-depth-stencil-antialias.html:
> > 1 tests failed

The part that was Firefox's bug should now be fixed in today's nightly build (2012-04-21):
  https://bugzilla.mozilla.org/show_bug.cgi?id=746296
But we'll still fail that test as long as Mesa returns MAX_SAMPLES > 1 without actually doing MSAA.

> > conformance/programs/program-test.html: 1 tests failed
> 
> > PASS linking should fail with in-use formerly good program, with
> > new bad shader attached
> > FAIL getError expected: NO_ERROR. Was INVALID_OPERATION : drawing
> > with a
> > valid program shouldn't generate a GL error
> 
> This sounded like it was going to be a Mesa bug, but this testcase
> passes:

This is indeed Mesa's bug: on failure, glLinkProgram should leave a previously-successfully-linked program intact. The testcase in your email doesn't seem to be re-linking the program with the bad shader, which would explain why it doesn't reproduce this issue.

Here is a small testcase that reproduces the issue for me on Mesa 7.11 (Ubuntu 11.10, r600g):
http://people.mozilla.org/~bjacob/link-failure-should-leave-valid-program-intact.html

> 
> Is it possible to run just a subtest?

The way I debugged this is I did 'view source' (ctrl+U), searched for some message that got printed just before the error, which pointed me to the relevant part of the code.

To reduce a testcase, check out the webgl repository so you can modify these tests locally:
 svn checkout https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl

To run tests locally without running into the strict origin policy, either use a http server, like
  python -m SimpleHTTPServer
or go to about:config and set
  security.fileuri.strict_origin_policy=false
but that is a rather insecure thing to do (do it only on a dedicated test profile).

> > conformance/renderbuffers/framebuffer-object-attachment.html: 3
> > tests failed
> 
> > Create and attach depthStencil renderbuffer
> > PASS depthStencilBuffer = gl.createRenderbuffer() is non-null.
> > PASS getError was expected value: NO_ERROR :
> > PASS gl.getRenderbufferParameter(gl.RENDERBUFFER,
> > gl.RENDERBUFFER_WIDTH) is width
> > PASS gl.getRenderbufferParameter(gl.RENDERBUFFER,
> > gl.RENDERBUFFER_HEIGHT) is height
> > FAIL gl.getRenderbufferParameter(gl.RENDERBUFFER,
> > gl.RENDERBUFFER_INTERNAL_FORMAT) should be 34041. Was 0.
> 
> [ and 2 others of this sort ]
> 
> I bet this will be our failure.  We don't have test coverage for
> GL_RENDERBUFFER_INTERNAL_FORMAT in piglit, which I'll try to fix.

Cool, let me know.

> 
> > conformance/textures/tex-image-and-sub-image-2d-with-image.html: 8
> > tests failed
> 
> I'm not sure what code path this is.

This was a bug in the test itself, which we fixed (the 1.0.1 tests are not finalized until multiple implementations pass them all, which is only starting to happen now).

The bug was that this test assumed no color management. I bet your system is color-managed. Fixed.

Now that multiple browsers/OSes/drivers pass all tests, it is likely that the conformance test suite will be officialized soon (maybe in a week or two). It would be great to be able to add Mesa and open-source drivers to the list of known-to-pass GL implementations. It seems that we're extremely close!

Cheers,
Benoit