Re: [Mesa-dev] [00/21] Last of SSO, take 47
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. This combination of use modes is a big part of the reason this has taken so long to finish. Gregory's initial patches had *no* support for rendezvous by location, and it was working with his shaders that also worked with AMD and NVIDIA. Also, if I recall correctly, all of the shaders in Serious Sam use rendezvous by name, but I could be mistaken. I believe use the exact same shader code in linked and separable modes. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [00/21] Last of SSO, take 47
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
Re: [Mesa-dev] [00/21] Last of SSO, take 47
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). pgpPxyWaFTwxQ.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [00/21] Last of SSO, take 47
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. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [00/21] Last of SSO, take 47
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. pgpZggEugACbe.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
