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

[Benoit Jacob]

----- Original Message -----
> On Mon, 23 Apr 2012 10:30:41 -0700 (PDT), Benoit Jacob
> <bjacob at mozilla.com> wrote:
> > 
> > 
> > ----- 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.
> 
> I did find this gem later:
> 
>     "If that program object that is in use is re-linked
>     unsuccessfully,
>      the link status will be set to FALSE, but existing executable
>      and
>      associated state will remain part of the current rendering state
>      until a subsequent call to UseProgram removes it from use."
> 
> Maybe they're testing that.  I wonder what possible use was imagined
> for
> forcing that sort of complexity on driver developers.

Yes, the public_webgl list got a reply quoting that sentence as the reason for the unit test's behavior. I must say I sympathize with you on this, but since it's what the spec says and what a majority of GL implementations do, let's keep it that way.

Cheers,
Benoit

>