[Mesa-dev] [RFC PATCH] glsl: Allow mixing of GLSL 1.40 and later shader versions.

Ian Romanick idr at freedesktop.org
Thu Oct 17 01:56:36 CEST 2013


On 10/16/2013 10:29 AM, Paul Berry wrote:
> ---
> 
> I'm not 100% sure this is the right way to go, and here's why:
> 
> Taken together, all the GLSL specs except GLSL 4.30 and GLSL 4.40 tell
> a consistent story: desktop shader versions 1.10 and 1.20 may be
> linked together, and desktop shader versions 1.40 and above may be
> linked together.  No other cross-version linking is allowed.
> 
> However, cross-version linking restrictions were explicitly removed in
> GLSL 4.30 (the change is listed under "Summary of Changes from Version
> 4.20 as "Remove cross-version linking restrictions.").  GLSL 4.30 and
> 4.40 state that *any* version of desktop GLSL may be linked with any
> other version of desktop GLSL.  (Note that cross-version linking is
> still prohibited for ES shaders).

This came from a Khronos bug that I submitted.  The problem is that no
other driver enforces the spec mandated restriction.  On top of that,
you can't fully enforce the restriction (without draw-time errors) with
separate shader objects.  I *thought* the change in 4.3 was to allow
mixed versions between stages, but mixing versions within a stage is
still forbidden.

> This leads to a conundrum.  Normally when the GLSL spec changes from
> one version to the next, we implement different rules depending on the
> user-supplied "#version" directive.  But we can't do that for
> cross-version linking rules since it's not clear which version of GLSL
> should apply.  Should we:
> 
> (a) always follow pre-GLSL 4.30 linking rules, since we don't support
> GLSL 4.30 yet?  (that's what this patch implements).
> 
> (b) always follow post-GLSL 4.30 linking rules, since they're probably
> the clearest reflection of the Khronos board's intent?
> 
> (c) make some kind of dynamic determination of which set of rules to
> follow?
> 
> FWIW, the NVIDIA proprietary driver for Linux (version 313.18) appears
> to implement (b).

There are different cases: intrastage and interstage.  I assume they
allow mixing interstage.  What about intrastage?

>  src/glsl/linker.cpp | 28 ++++++++++++++++++++--------
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index 9095a40..1dac85c 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -2057,17 +2057,29 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog)
>        }
>     }
>  
> -   /* Previous to GLSL version 1.30, different compilation units could mix and
> -    * match shading language versions.  With GLSL 1.30 and later, the versions
> -    * of all shaders must match.
> +   /* For desktop GLSL, versions 1.10 and 1.20 may be linked together, and
> +    * versions 1.40 and later may be linked together.  But version 1.30 may
> +    * not be linked with any other version, and versions prior to 1.30 may not
> +    * be linked to versions after 1.30.
>      *
>      * GLSL ES has never allowed mixing of shading language versions.
>      */
> -   if ((is_es_prog || max_version >= 130)
> -       && min_version != max_version) {
> -      linker_error(prog, "all shaders must use same shading "
> -		   "language version\n");
> -      goto done;
> +   if (is_es_prog) {
> +      if (min_version != max_version) {
> +         linker_error(prog, "all shaders must use same shading "
> +                      "language version\n");
> +         goto done;
> +      }
> +   } else {
> +      if (min_version < 130 && max_version >= 130) {
> +         linker_error(prog, "GLSL versions prior to 1.30 may not be linked "
> +                      "with GLSL versions 1.30 and above\n");
> +         goto done;
> +      } else if (min_version == 130 && max_version > 130) {
> +         linker_error(prog, "GLSL version 1.30 may not be linked with GLSL "
> +                      "versions above 1.30\n");
> +         goto done;
> +      }
>     }
>  
>     prog->Version = max_version;
> 



More information about the mesa-dev mailing list