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

[Ian Romanick]

On 04/24/2012 01:57 AM, Eric Anholt wrote:
> 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.

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?