[Mesa-dev] sampler arrays indexed with non-constant expressions

[Ian Romanick]

On 11/19/2013 01:16 AM, Erik Faye-Lund wrote:
> On Mon, Nov 18, 2013 at 9:04 PM, Paul Berry <stereotype441 at gmail.com> wrote:
>> On 17 November 2013 00:24, Victor Luchitz <vluchits at gmail.com> wrote:
>>> If compiler actually attempted to unroll the loop above, it would notice
>>> that the does compile correctly. Instead it just emits and error and in my
>>> opinion, contradicts the comment above but not allowing the "useful thing"
>>> in question.
>>>
>>> Can the compiler be changed to _first_ attempt to unroll the loop and then
>>> check for sampler array indices being constants?
>>
>>
>> Thanks for the feedback, Victor.  We are always interested in hearing
>> suggestions about how to improve Mesa.
>>
>> Unfortunately, in this case, your suggestion would make Mesa non-conformant
>> with the GLSL specs because it would allow shaders that are prohibited by
>> the spec.  Generally we try to avoid this sort of non-spec-conformance
>> because it leads to portability problems for developers like you (e.g. your
>> shader works with Mesa, but it fails with other GL implementations).  A
>> further problem is that Mesa has heuristics to decide whether to unroll
>> loops; if we followed your suggestion, then your shader might work today,
>> but fail tomorrow if you make a small change to the shader that makes Mesa
>> decide not to unroll the loop (or we make a change to the heuristics in a
>> future release of Mesa).
> 
> Just as minor nit, I'd like to point out that the OpenGL ES 2.0
> shading language specification defines a concept of
> "constant-index-expressions" which includes loop indices, and allows
> sampler arrays to be indexed by these expressions. This only works
> because it at the same time does not allow arbitrary loops. See
> appendix A, section 4 and 5 of the spec for the details.

Right.  Basically the ES 2.0 limitation is that any loop can be
unrolled... because quite a bit of the original ES 2.0 target hardware
didn't have *any* branching.  This was hardware like i915 or r300.

The case that Paul describes isn't hypothetical, either.  We actually
encountered this a couple years ago.  There was something in the loop
that prevented the compile from unrolling it, and the texture accesses
in the loop caused assertion failures.  We eventually made the loop
unroll, but I seem to recall that had other bad side effects.  I *thin*
the problem was the loop, for some reason or another, had a huge number
of instructions.  I'm fairly sure there was an associated bug report,
but it's probably too much effort to make it worth finding.

> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev