[Public WebGL] possible non-passable test: program-test.html requires program state to be left untouched by a failed link

Gregg Tavares (勤) [email protected]
Mon Apr 23 10:55:45 PDT 2012


Keep reading, page 31

While a valid program object is in use, applications are free to modify
attached
shader objects, compile attached shader objects, attach additional shader
objects,
and detach shader objects. These operations do not affect the link status
or executable code of the program object.

If the program object that is in use is re-linked successfully, the
LinkProgram
command will install the generated executable code as part of the current
rendering
state if the specified program object was already in use as a result of a
previous call
to UseProgram.

*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. After such a program is removed from use, it can not be made
part of the*
*current rendering state until it is successfully re-linked.*


On Mon, Apr 23, 2012 at 10:46 AM, Benoit Jacob <[email protected]> wrote:

>
> Hi,
>
> Kudos to Eric Anholt on the mesa-dev list for finding this.
>
> program-test.html contains this:
>
>    gl.attachShader(progGood2, fsBad);
>    gl.linkProgram(progGood2);
>    assertMsg(gl.getProgramParameter(progGood2, gl.LINK_STATUS) == false,
>              "linking should fail with in-use formerly good program, with
> new bad shader attached");
>
>    // Invalid link leaves previous valid program intact.
>    gl.drawArrays(gl.TRIANGLES, 0, 3);
>    glErrorShouldBe(gl, gl.NO_ERROR, "drawing with a valid program
> shouldn't generate a GL error");
>
> As the comment says, this requires a WebGL implementation to keep programs
> intact after a failed link.
>
> The WebGL spec doesn't seem to say anything specific about that, and the
> OpenGL ES 2.0.25 spec, page 30, says:
>
> "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."
>
> Thus, this test seems incorrect.
>
> OK to fix it by enforcing the above-quoted behavior from the GLES2 spec?
> This should be easy to implement in WebGL implementations in a way that
> doesn't depend on drivers.
>
> Cheers,
> Benoit
>
> -----------------------------------------------------------
> You are currently subscribed to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120423/68970154/attachment.html>


More information about the public_webgl mailing list