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

[Benoit Jacob]

----- Original Message -----
> On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob
> <bjacob at mozilla.com> wrote:
> > > > 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.
> 
> It should?  I read the opposite in this quote from the GL 3.0 spec:
> 
>     "Linking will also fail if one or more of the shader objects,
>      attached to program are not compiled successfully, or if more
>      active uniform or active sampler variables are used in program
>      than
>      allowed (see section 2.20.3). If LinkProgram failed, any
>      information about a previous link of that program object is
>      lost. Thus, a failed link does not restore the old state of
>      program."

Thanks, I hadn't questioned that the test might be wrong, but now I agree with you. Also, the same phrasing is found in the OpenGL ES 2.0.25 spec page 30:

"If LinkProgram failed, any information about a previous link of that program object is lost. Thus, a failed link does not restore the old state of program."

Reporting this to the WebGL mailing list.

Benoit


> 
> > > > 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.
> 
> I wrote a test that checked that for all the internalformats we knew
> of
> for renderbuffers, the RB had that GL_RENDERBUFFER_INTERNAL_FORMAT.
>  The
> test passed.  I'll need to poke at the webgl testcase to figure out
> where to look next.
>