[Mesa-dev] [PATCH 1/2] glsl: Don't remove XFB-only varyings.
Timothy Arceri
timothy.arceri at collabora.com
Sun Apr 3 11:34:05 UTC 2016
On Sun, 2016-04-03 at 01:37 -0700, Kenneth Graunke wrote:
> Consider the case of linking a program with both a vertex and
> fragment
> shader. The VS may compute output varyings that are intended for
> transform feedback, and not read by the fragment shader.
>
> In this case, var->data.is_unmatched_generic_inout will be true,
> but we still cannot eliminate the varyings. We need to also check
> !var->data.is_xfb_only.
>
> Fixes failures in ES31-CTS.gpu_shader5.fma_precision_*, which happen
> to use transform feedback in a way we apparently hadn't seen before.
Hmm ... are you sure there is not something else going wrong here
somewhere? is_xfb_only is set in the same code block that should change
is_unmatched_generic_inout to false.
if (matched_candidate->toplevel_var
>data.is_unmatched_generic_inout) {
matched_candidate->toplevel_var->data.is_xfb_only = 1;
matches.record(matched_candidate->toplevel_var, NULL);
}
matches.record() should set is_unmatched_generic_inout to false and
setup everything else needed for xfb. Seems like there is another bug
here somewhere.
>
> Cc: mesa-stable at lists.freedesktop.org
> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
> ---
> src/compiler/glsl/link_varyings.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/glsl/link_varyings.cpp
> b/src/compiler/glsl/link_varyings.cpp
> index e9d0067..87606be 100644
> --- a/src/compiler/glsl/link_varyings.cpp
> +++ b/src/compiler/glsl/link_varyings.cpp
> @@ -488,7 +488,7 @@ remove_unused_shader_inputs_and_outputs(bool
> is_separate_shader_object,
> * its value is used by other shader stages. This will cause
> the
> * variable to have a location assigned.
> */
> - if (var->data.is_unmatched_generic_inout) {
> + if (var->data.is_unmatched_generic_inout && !var-
> >data.is_xfb_only) {
> assert(var->data.mode != ir_var_temporary);
> var->data.mode = ir_var_auto;
> }
More information about the mesa-dev
mailing list