[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 <bjacob@mozilla.com> wrote:


Kudos to Eric Anholt on the mesa-dev list for finding this.

program-test.html contains this:

   gl.attachShader(progGood2, fsBad);
   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.


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl