[Mesa-dev] glsl: should uniform initializers be allowed in GLSL ES 3.00?

[Ian Romanick]

On 05/14/2014 11:52 AM, Matt Turner wrote:
> On Wed, May 14, 2014 at 10:00 AM, Aras Pranckevicius <aras at unity3d.com> wrote:
>> Hi,
>>
>> Mesa's ast_to_hir.cpp does a check like:
>>
>>   state->check_version(120, 0, &initializer_loc,
>>                            "cannot initialize uniforms");
>>
>> i.e. it does not allow uniform initializers on GLSL ES 3.00.
>>
>> Upon my reading of the spec, I can't find any place where that would be
>> disallowed. ES 3.00 seems to be based on GLSL 3.3, with a bunch of stuff
>> removed and added. Uniform initializers aren't listed in the "removed"
>> section (spec 3.00.4, section 1.1.4). So maybe the check should be changed
>> to allow 300 in the ES min version?
> 
> The GLSL 3.30 spec says
> 
>> All uniform variables are read-only and are initialized externally either at link time or through the API. The link time initial value is either the value of the variable's initializer, if present, or 0 if no initializer is present. Sampler types cannot have initializers.
> 
> While the GLSL ES 3.00 (.4) spec says (The GLSL ES 3.1 spec contains
> this wording too)
> 
>> All uniform variables are read-only. They are initialized to 0 at link time and may be updated through the API.
> 
> So I think we're correct in disallowing it.
> 
> Chalk it up to another trivial divergence of ES in unexpected way.
> 
> Ian, does it seem like we can make a really trivial extension that
> gives you back the wording in the Desktop GLSL spec? Are there other
> interactions we need to think about? There's already wording
> explicitly disallowing initializing samplers in a shader.

I don't see any reason that we couldn't.  It would probably take longer
to spec it than to implement it. :)  It's /probably/ more than just
adding that one sentence.

Applications would still need to enable that extension in the shader...
and the work-arounds for drivers that don't support it would be ugly.  I
think I'd want to have at least one other vendor agree to implement the
extension before it would be worth the effort for anyone involved (us or
ISV).