Ian Romanick <i...@freedesktop.org> writes:
> On 04/30/2014 05:13 PM, Eric Anholt wrote:
>> Ian Romanick <i...@freedesktop.org> writes:
>>
>>> On 04/30/2014 12:41 PM, Eric Anholt wrote:
>>>> Ian Romanick <i...@freedesktop.org> writes:
>>>>
>>>>> A lot the patches in this series were slightly reworked to incorporate
>>>>> Eric's feedback (remove ir_variable::user_location) on the previous
>>>>> attempt. Other than that change, I patch 1 is new, and patch 16 adds
>>>>> previously missing display list support.
>>>>
>>>> Patch 2, 3, 13, 16, 17, 18, 20, 21 are:
>>>>
>>>> Reviewed-by: Eric Anholt <e...@anholt.net>
>>>>
>>>> I think my patch 15 comments were minor, and if you agree with them
>>>> (meaning I actually understood what was going on), then apply the r-b
>>>> there too.
>>>>
>>>> Patch 19 is:
>>>>
>>>> Acked-by: Eric Anholt <e...@anholt.net>
>>>>
>>>> Patch 14 I don't think is needed (since we've got explicit locations
>>>> being assigned to corresponding varying slots).
>>>
>>> The sorting is so that a vertex shader that does
>>>
>>> out vec4 a;
>>> out vec4 b;
>>>
>>> and a fragment shader that does
>>>
>>> in vec4 b;
>>> in vec4 a;
>>>
>>> will assign the same locations for a and b. If both shaders have the
>>> same set of varyings, they'll all get the same locations. Without
>>> sorting, we assign the locations based on the order in which variables
>>> appear in the shader text.
>>
>> In SSO, we aren't assigning locations, because we have explicit
>> locations for everything. In non-SSO, we either have explicit
>> locations, or we're matching ir_variables up by name and assigning the
>> dynamic locations to the same name across both producer and consumer.
>
> Ah, but we are. Rendezvous by name still works, even with separable
> programs. Rendezvous by location works even with explicitly linked
> programs.
>
> Applications are even allowed to use explicit locations for some
> varyings and rendezvous by name for others.
>
> Relevant spec text:
>
> With separable program objects, interfaces between shader stages may
> involve the outputs from one program object and the inputs from a
> second program object. For such interfaces, it is not possible to
> detect mismatches at link time, because the programs are linked
> separately. When each such program is linked, all inputs or outputs
> interfacing with another program stage are treated as active. The
> linker will generate an executable that assumes the presence of a
> compatible program on the other side of the interface. If a mismatch
> between programs occurs, no GL error will be generated, but some or all
> of the inputs on the interface will be undefined.
>
> At an interface between program objects, the set of inputs and outputs are
> considered to match exactly if and only if:
>
> * The built-in input and output blocks used on the interface
> ("gl_PerVertex" or "gl_PerFragment") match, as described below.
>
> * Every declared input block or variable must have a matching output, as
> described above.
>
> * There are no output blocks or user-defined output variables
> declared without a matching input block or variable declaration.
>
> When the set of inputs and outputs on an interface between programs
> matches exactly, all inputs are well-defined unless the corresponding
> outputs were not written in the previous shader. However, any mismatch
> between inputs and outputs results in all inputs being undefined except
> for cases noted below. Even if an input has a corresponding output
> that matches exactly, mismatches on other inputs or outputs may
> adversely affect the executable code generated to read or write the
> matching variable.
>
> The important part is "...the set of inputs and outputs on an interface
> between programs matches exactly..." from the last paragraph. If the
> declared inputs to the fragment shader exactly match the declared
> outputs of the vertex shader, it "just works." The implication being
> that locations are assigned by the linker in a deterministic way.OK, that really surprised me. I never expected the spec to allow that. Patch 14, then, is also: Reviewed-by: Eric Anholt <e...@anholt.net>
pgpqaNjk3jcbV.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
