On Thu, 2018-01-11 at 16:51 +0100, Juan A. Suarez Romero wrote:
> On Wed, 2018-01-10 at 14:04 +0200, Tapani Pälli wrote:
> > 
> > On 01/08/2018 03:19 PM, Juan A. Suarez Romero wrote:
> > > Please, could someone take a look at this patch? Thanks in advance.
> > > 
> > 
> > This looks correct to me. Is there some dEQP/Piglit test for this situation?
> 
> 
> Yes. It fixes KHR-GL*.shaders.uniform_block.common.name_matching.
> 
> I'll include the tests in the commit message.
> 

Tapani, with the previous comment about adding the fixed test in the
commit message, is this Rb ?

Thanks!


>       J.A.
> 
> > 
> > >   J.A.
> > > 
> > > On Mon, 2017-12-04 at 17:35 +0100, Juan A. Suarez Romero wrote:
> > > > According with OpenGL GLSL 4.20 spec, section 4.3.9, page 57:
> > > > 
> > > >     "It is a link-time error if any particular shader interface
> > > >      contains:
> > > >        - two different blocks, each having no instance name, and each
> > > >          having a member of the same name, or
> > > >        - a variable outside a block, and a block with no instance name,
> > > >          where the variable has the same name as a member in the block."
> > > > 
> > > > This means that it is a link error if for example we have a vertex
> > > > shader with the following definition.
> > > > 
> > > >    "layout(location=0) uniform Data { float a; float b; };"
> > > > 
> > > > and a fragment shader with:
> > > > 
> > > >    "uniform float a;"
> > > > 
> > > > As in both cases we refer to both uniforms as "a", and thus using
> > > > glGetUniformLocation() wouldn't know which one we mean.
> > > > ---
> > > >   src/compiler/glsl/linker.cpp | 23 +++++++++++++++++++++++
> > > >   1 file changed, 23 insertions(+)
> > > > 
> > > > diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
> > > > index 33fd76deae9..b6de7b54ae3 100644
> > > > --- a/src/compiler/glsl/linker.cpp
> > > > +++ b/src/compiler/glsl/linker.cpp
> > > > @@ -1111,6 +1111,29 @@ cross_validate_globals(struct gl_shader_program 
> > > > *prog,
> > > >               return;
> > > >            }
> > > >   
> > > > +         /* In OpenGL GLSL 4.20 spec, section 4.3.9, page 57:
> > > > +          *
> > > > +          *   "It is a link-time error if any particular shader 
> > > > interface
> > > > +          *    contains:
> > > > +          *
> > > > +          *    - two different blocks, each having no instance name, 
> > > > and each
> > > > +          *      having a member of the same name, or
> > > > +          *
> > > > +          *    - a variable outside a block, and a block with no 
> > > > instance name,
> > > > +          *      where the variable has the same name as a member in 
> > > > the block."
> > > > +          */
> > > > +         if (var->data.mode == existing->data.mode &&
> > > > +             var->get_interface_type() != 
> > > > existing->get_interface_type()) {
> > > > +            linker_error(prog, "declarations for %s `%s` are in "
> > > > +                         "%s and %s\n",
> > > > +                         mode_string(var), var->name,
> > > > +                         existing->get_interface_type() ?
> > > > +                           existing->get_interface_type()->name : 
> > > > "outside a block",
> > > > +                         var->get_interface_type() ?
> > > > +                           var->get_interface_type()->name : "outside 
> > > > a block");
> > > > +
> > > > +            return;
> > > > +         }
> > > >            /* Only in GLSL ES 3.10, the precision qualifier should not 
> > > > match
> > > >             * between block members defined in matched block names 
> > > > within a
> > > >             * shader interface.
> > > 
> > > _______________________________________________
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > > 
> > 
> > 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to