[Mesa-dev] [PATCH 3/3] glsl: Generate smaller values for uniform locations

Fredrik Höglund fredrik at kde.org
Mon Jun 10 15:54:26 PDT 2013


On Monday 10 June 2013, Brian Paul wrote:
> On 06/10/2013 11:52 AM, Ian Romanick wrote:
> > From: Ian Romanick <ian.d.romanick at intel.com>
> >
> > Previously we would generate uniform locations as (slot << 16) +
> > array_index.  We do this two handle applications that assume the

to handle

> > location of a[2] will be +1 from the location of a[1].  This resulted in
> > every uniform location being at least 0x10000.  We've now encountered
> > two applications that assume uniform values will be smaller.
> >
> > NEITHER BEHAVIOR IS GUARNATEED
> 
> GUARANTEED
> 
>   OR IMPLIED BY ANY VERSION OF OpenGL.

I wonder if OpenGL doesn't in fact imply this.

Section 4.4.3 of the GLSL 4.30 spec says this about the location layout-
qualifier:

	"Individual elements of a uniform array are assigned consecutive locations
	 with the first element taking location /location/."

and

	"The first inner-most scalar, vector or matrix member or element takes
	 the specified /location/ and the compiler assigns the next inner-most
	 member or element the next incremental location value. Each subsequent
	 inner-most member or element gets incremental locations for the entire
	 structure or array. This rule applies to nested structures and arrays and
	 gives each inner-most scalar, vector, or matrix type a unique location.
	 For arrays without an explicit size, the size is calculated based on its
	 static usage. When the linker generates locations for uniforms without an
	 explicit location, it assumes for all uniforms with an explicit location all
	 their array elements and structure members are used and the linker will
	 not generate a conflicting location, even if that element of member is
	 deemed unused."

It seems unlikely to me that the intent is for the compiler to only apply
this rule to uniforms with an explicit location, even though the spec can
be read that way.

Fredrik



More information about the mesa-dev mailing list