I have now a pending patch for the front end. Two or three extra things may
also be easily done but I prefer to wait remarks from people rather proposing a
bigger patch with a higher probability to require modifications :)
I am planning to look at the i965 back end. I saw that there are several
passes applied in the fragment shader. They improve the code (in particular
"de-swizzle-de-vectorize" it as far as I understand)
What is the best strategy if I want to modify it? Pulling you tree and mailing
patches to you or pulling the main git tree and posting patches here? My
concern is about Sandybride. If you are modifying a lot of code, it may better
for you to centralize the modifications in the i965 backend.
Cheers,
Ben
________________________________________
From: Eric Anholt [e...@anholt.net]
Sent: Monday, July 19, 2010 2:46 PM
To: Segovia, Benjamin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] Optimizations in mesa shader compiler
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).
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
