[Mesa-dev] [PATCH 2/9] glsl: merge layouts into the default one as the last step in interface blocks

Andres Gomez agomez at igalia.com
Mon Oct 24 14:07:32 UTC 2016


On Mon, 2016-10-24 at 12:23 +1100, Timothy Arceri wrote:
> On Sat, 2016-10-22 at 23:09 +0300, Andres Gomez wrote:
> > Consider this example:
> > 
> >     " #version 150 core
> >       #extension GL_ARB_shading_language_420pack: require
> >       #extension GL_ARB_explicit_attrib_location: require
> > 
> >       layout(location=0) out vec4 o;
> >       layout(binding=2) layout(binding=3, std140) uniform U {
> >           vec4 a;
> >       } u[2];"
> > 
> > As there is 2 layout-qualifiers for the uniform U and the binding
> > layout-qualifier-id is duplicated, the rules set by the
> > ARB_shading_language_420pack spec state that the rightmost should
> > prevail.
> > 
> > Our ast_type_qualifier merges with others in a way that if the value
> > for a layout-qualifier-id is set in both, the object being merged
> > overwrites the value of the object invoking the merge. Hence, the
> > merge has to happen from the left layout towards the right one and
> > this was not happening for interface blocks because we were merging
> > into the default layout qualifier.
> > 
> > Now, the merge is done from left to right and, as a last step, we
> > merge into the default layout qualifier if needed, so the values of
> > the explicit layouts prevail over it.
> > 
> > Signed-off-by: Andres Gomez <agomez at igalia.com>
> 
> 
> That patch looks logically correct. However I'd really like it if you
> could rename the existing layout member to default_layout and make the
> new one layout rather than layout_helper.
> 
> I understand this will likely be a few more changes but the end result
> will be much easier to follow.

I actually have an implementation like that in a different branch. That
was my first attempt, I changed later to the current one because I
thought it was easier to understand that way ☺

I will recover that other implementation.

-- 
Br,

Andres


More information about the mesa-dev mailing list