[Mesa-dev] Optimizations in mesa shader compiler

[Eric Anholt]

On Tue, 13 Jul 2010 16:46:21 -0700, "Segovia, Benjamin" <benjamin.segovia at 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100719/32f588a8/attachment.pgp>