[Mesa-dev] [PATCH] GLSL: fix too eager constant variable optimization

[Aras Pranckevicius]

> - 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,
https://github.com/aras-p/glsl-optimizer) that's not up to date with
latest master.


> - It seems kludgy to add a visitor for ir_function_signature that loops
> through all the parameters, since the default hierarchial visitor for
> ir_function_signature already does that.  Why not just modify the
> ir_variable visitor so that it increments entry->assignment_count when it
> visits a variable whose mode is ir_var_function_in or ir_var_function_inout?
> (Note that the ability to distinguish between function "in" variables and
> shader "in" variables was added in commit 42a29d8, the commit I mentined
> above).

Good point, that should be a better approach.



> Although I agree that opt_constant_variable has problems and could be
> improved, it seems like I must be missing some crucial piece of information
> here, since I can't reproduce the bug and I can't understand why your patch
> would have any effect.  I've made a shader_runner test to try to demonstrate
> the problem (attached), and it works fine on mesa master as well as the 9.1,
> 9.0, 8.0, and 7.11 branches.  Can you help me understand what I'm missing?

Yeah perhaps it can't ever manifest in Mesa's context. In my fork, I'm
using Mesa's GLSL compiler & optimization passes to do a GLSL-to-GLSL
compiler (sounds weird? it kind of is, but works around many mobile
platform drivers being really, really weak at GLSL optimization). I do
optimization passes very similarly to Mesa, but slightly different at
places.

But since it's not clear whether my improvements bring any benefit in
the context of Mesa, then maybe my patch should just be ignored. And
sorry for the wasted time then.



> Finally, in the future would you mind posting patches to the mailing list
> as inline text rather than attachments?  ("git send-email" is a convenient
> way to do this.)

Will do.


--
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info