On 11/19/2013 01:16 AM, Erik Faye-Lund wrote: > On Mon, Nov 18, 2013 at 9:04 PM, Paul Berry <stereotype...@gmail.com> wrote: >> On 17 November 2013 00:24, Victor Luchitz <vluch...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
