[Mesa-dev] Should we add new error cases to stable releases?

Matt Turner mattst88 at gmail.com
Tue Jul 30 13:13:47 PDT 2013


On Tue, Jul 30, 2013 at 12:13 PM, Carl Worth <cworth at cworth.org> wrote:
> Hi Ken,
>
> In the last stable-release cycle you argued for not cherry picking
> commit fcaa48d9cc8937e0ceb59dfd22ef5b6e6fd1a273 on the grounds that
> we shouldn't change mesa to be strictly more strict in a stable release.
>
> That is, adding a new error case to the compiler cannot actually cause a
> valid program to start working, (which would be a nice bug fix), but
> could potentially cause an invalid program to stop working (which could
> be regarded as a regression).
>
> The same reasoning seems to disqualify the below patch. Do you agree?
>
> Anyone else have input on this issue? If we agree on the rationale, I'd
> like to codify it with some language in our documentation for
> stable-branch criteria. Something like:
>
>         Note: Not all bug fixes are automatically suitable for the
>         stable branch.
>
>         For example, a patch that makes the implementation more strict,
>         (such as detecting some invalid GLSL code that was previously
>         silently accepted), can be rejected by the stable-branch
>         maintainer. The rationale is that a patch like this can cause a
>         program which was previously working as desired to now stop
>         working due to the new error case. From the point of view of the
>         user of such an application, that's a regression that we do not
>         want to allow during a stable release.
>
> -Carl
>
> commit 17856726c94000bf16156f7f9acea77a271a6005
> Author: Kenneth Graunke <kenneth at whitecape.org>
> Date:   Fri Jul 26 21:18:56 2013 -0700
>
>     glsl: Disallow auxiliary storage qualifiers on FS outputs.
>
>     This has always been an error; we just forgot to check for it.
>
>     Fixes Piglit's no-aux-qual-on-fs-output.frag.
>
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67333
>     Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
>     Reviewed-by: Matt Turner <mattst88 at gmail.com>
>     Cc: mesa-stable at lists.freedesktop.org
>
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 2569cde..598da92 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -2927,6 +2927,20 @@ ast_declarator_list::hir(exec_list *instructions,
>                            "'centroid in' cannot be used in a vertex shader");
>        }
>
> +      /* Section 4.3.6 of the GLSL 1.30 specification states:
> +       * "It is an error to use centroid out in a fragment shader."
> +       *
> +       * The GL_ARB_shading_language_420pack extension specification states:
> +       * "It is an error to use auxiliary storage qualifiers or interpolation
> +       *  qualifiers on an output in a fragment shader."
> +       */
> +      if (state->target == fragment_shader &&
> +          this->type->qualifier.flags.q.out &&
> +          this->type->qualifier.has_auxiliary_storage()) {
> +         _mesa_glsl_error(&loc, state,
> +                          "auxiliary storage qualifiers cannot be used on "
> +                          "fragment shader outputs");
> +      }
>
>        /* Precision qualifiers exists only in GLSL versions 1.00 and >= 1.30.
>         */

I think that this patch /should/ go in, since it was a fix for a new extension.

9.2 will be the first version of Mesa to ship with support for
ARB_shading_language_420pack, so the branch should contain bug fixes
for the extension.


More information about the mesa-dev mailing list