On 3 March 2013 00:44, Aras Pranckevicius a...@unity3d.com wrote:
opt_constant_variable was marking a variable as constant as long as
there was
exactly one constant assignment to it, but did not take into account
that this
assignment might be in a dynamic branch or a loop.
Was happening
- The patch doesn't compile cleanly on master. In particular, it looks
like it was made using a version of the code prior to commit 42a29d8 (glsl:
Eliminate ambiguity between function ins/outs and shader ins/outs).
Whoops, indeed. I made in my own modified Mesa fork (GLSL Optimizer,
opt_constant_variable was marking a variable as constant as long as there was
exactly one constant assignment to it, but did not take into account that
this
assignment might be in a dynamic branch or a loop.
Was happening on a fragment shader like this:
uniform float mode;
float func
Now, looking further this optimization pass should also not mark variables
as const if there was a dereference of them before that first assignment. I
had code to do this (a hashtable that would track dereferences before
assignment is done). But couldn't come up with a test case that would
Hi,
opt_constant_variable was marking a variable as constant as long as there
was exactly one constant assignment to it, but did not take into account
that this assignment might be in a dynamic branch or a loop.
Was happening on a fragment shader like this:
uniform float mode;
float func (float
On 03/01/2013 02:02 AM, Aras Pranckevicius wrote:
Hi,
opt_constant_variable was marking a variable as constant as long as
there was exactly one constant assignment to it, but did not take into
account that this assignment might be in a dynamic branch or a loop.
Was happening on a fragment
On 1 March 2013 02:02, Aras Pranckevicius a...@unity3d.com wrote:
Hi,
opt_constant_variable was marking a variable as constant as long as there
was exactly one constant assignment to it, but did not take into account
that this assignment might be in a dynamic branch or a loop.
Was
