On 04/24/2012 01:57 AM, Eric Anholt wrote:
On Mon, 23 Apr 2012 10:30:41 -0700 (PDT), Benoit Jacob<bja...@mozilla.com>
wrote:
----- Original Message -----
On Sat, 21 Apr 2012 08:09:33 -0700 (PDT), Benoit Jacob
<bja...@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.
I have a theory that may or may not be valid. Program objects are
shared. The behavior implied by this bit of spec language is that
relinking a program in one context won't break rendering in another
context that is using that program.
It's also possible that the language was written with the assumption
that there was no such thing as state-dependent recompiles. Linking the
program generates an executable, and you're done, right?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
