On Tue, 13 Jul 2010 16:46:21 -0700, "Segovia, Benjamin"
<benjamin.sego...@intel.com> wrote:
> To be more precise,
> - The shader compiler present in src/mesa/slang is used.
>
> - The glsl shader (randomly taken on the net) is:
> void main(){
> const float PI = 3.14159265358979323846264;
> const float angle = 45.0;
> const float rad_angle = angle*PI/180.0;This will definitely get constant folded by the new compiler. > vec4 a = gl_Vertex; > vec4 b = a; gratuitous moved channels here should get removed by Mesa IR optimization I think. > b.x = a.x*cos(rad_angle) - a.y*sin(rad_angle); > b.y = a.y*cos(rad_angle) + a.x*sin(rad_angle); Not today, but in the next week or two (Ken's working on it), the builtin function calls of constant values will get folded by the new compiler. Also on my todo list is recognizing things like this "b.y = dot(a.yx, vec2(const, const))". As you noted in other replies, a bunch of things are not obvious to optimize in Mesa IR when the target is the 965 fragment shader. Our plan is to eventually build a native glsl2 IR -> 965 FS codegen, but in the short term one of my plans is to put a pass in for 965 fragment shaders that flattens expressions and hacks them up into their component channels (where appropriate -- not texture sampling), then split vector variables referenced only channel-wise into multiple scalar variables. Then the Mesa IR generated will have the optimizations we wanted already done, and the 965 fragment shader code generated shouldn't look so bad (though it'll still lack compute-to-MRF, as you noted).
pgpZYzmuKf4sl.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
