Cheers,
Ben
________________________________________
From: mesa-dev-bounces+benjamin.segovia=intel....@lists.freedesktop.org
[mesa-dev-bounces+benjamin.segovia=intel....@lists.freedesktop.org] On Behalf
Of Segovia, Benjamin [benjamin.sego...@intel.com]
Sent: Wednesday, July 14, 2010 3:15 PM
To: Brian Paul
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] Optimizations in mesa shader compiler
I started yesterday to investigate. I am afraid this is not a bug. Constant are put into
variables and then the compiler lost the knowledge that there are still constant
variables. Strangely, early constant folding (in the parser) tracks the
"constantness" down but once the parse tree is built, it seems that the
constant tracking for the AST construction is somehow too late to make it easy.
I am looking to all that stuff anyway
Cheers,
Ben
________________________________________
From: Brian Paul [bri...@vmware.com]
Sent: Wednesday, July 14, 2010 12:54 PM
To: Segovia, Benjamin
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] Optimizations in mesa shader compiler
On 07/14/2010 12:27 PM, Segovia, Benjamin wrote:
> Actually, even the computation of rad_angle is ignored at compile time.
Sounds like a bug/regression. Could you look into that?
> I was also thinking about more optimizations in the final GPU code
i.e. contuining what has been started with the _mesa_optimize
function. rather working directly on the ir tree. Not sure of what is
the best strategy. I actually output random shaders from warsow,
openarena and nexuiz. For both GPU code and native Intel Gen code,
there are clear room for improvements. I am not sure if there are easy
to do (compared to pure scalar code, I imagine the main problem is to
handle the swizzling thing).
Well, there's different types of optimizations that can be made at
both levels. Things like function call inlining, loop unrolling,
constant folding and common subexpression elimination are easier done
at the high level while peephole and scheduling optimizations would be
done at the lower GPU instruction level.
> So, even with glsl2, optimizing the final GPU code optimization
pass would be still usefull (except if glsl2 properly optimizes
everything before)
Sure.
-Brian
> Ben
> ________________________________________
> From: Brian Paul [bri...@vmware.com]
> Sent: Wednesday, July 14, 2010 7:54 AM
> To: Segovia, Benjamin
> Cc: mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] Optimizations in mesa shader compiler
>
> On 07/13/2010 05:46 PM, Segovia, Benjamin 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;
>> vec4 a = gl_Vertex;
>> vec4 b = a;
>>
>> b.x = a.x*cos(rad_angle) - a.y*sin(rad_angle);
>> b.y = a.y*cos(rad_angle) + a.x*sin(rad_angle);
>> gl_Position = gl_ModelViewProjectionMatrix*b;
>> }
>>
>> - IR Output produced is:
>> # Vertex Program/Shader 1
>> 0: MOV TEMP[0].x, CONST[0].xxxx;
>> 1: MUL TEMP[1].x, CONST[0].yyyy, TEMP[0].xxxx;
>> 2: RCP TEMP[1].z, CONST[0].zzzz;
>> 3: MUL TEMP[0].w, TEMP[1].xxxx, TEMP[1].zzzz;
>> 4: MOV TEMP[0].z, TEMP[0].wwww;
>> 5: MOV TEMP[1].xz, INPUT[0];
>> 6: MOV TEMP[1].xzw, INPUT[0];
>> 7: COS TEMP[0].w, TEMP[0].wwww;
>> 8: MUL TEMP[2].x, INPUT[0].xxxx, TEMP[0].wwww;
>> 9: SIN TEMP[0].w, TEMP[0].zzzz;
>> 10: MUL TEMP[2].y, INPUT[0].yyyy, TEMP[0].wwww;
>> 11: SUB TEMP[1].x, TEMP[2].xxxx, TEMP[2].yyyy;
>> 12: COS TEMP[2].x, TEMP[0].zzzz;
>> 13: SIN TEMP[2].y, TEMP[0].zzzz;
>> 14: MUL TEMP[2].z, INPUT[0].xxxx, TEMP[2].yyyy;
>> 15: MAD TEMP[2].y, INPUT[0].yyyy, TEMP[2].xxxx, TEMP[2].zzzz;
>> 16: MUL TEMP[0], STATE[2], TEMP[2].yyyy;
>> 17: MAD TEMP[2], STATE[1], TEMP[1].xxxx, TEMP[0];
>> 18: MAD TEMP[0], STATE[3], TEMP[1].zzzz, TEMP[2];
>> 19: MAD TEMP[2], STATE[4], TEMP[1].wwww, TEMP[0];
>> 20: MOV OUTPUT[0], TEMP[2];
>> 21: END
>> */
>> /* Parameters / constants */
>> /*
>> dirty state flags: 0x3
>> param[0] sz=3 CONST (null) = {3.14, 45, 180, 3.14}
>> param[1] sz=4 STATE state.matrix.mvp.transpose.row[0] = {0, 0, 0, 0}
>> param[2] sz=4 STATE state.matrix.mvp.transpose.row[1] = {0, 0, 0, 0}
>> param[3] sz=4 STATE state.matrix.mvp.transpose.row[2] = {0, 0, 0, 0}
>> param[4] sz=4 STATE state.matrix.mvp.transpose.row[3] = {0, 0, 0, 0}
>> */
>>
>> - Finally, Gen code also includes the constant computations in the
shader.
>>
>> Ben
>>
>> ________________________________________
>> From:
mesa-dev-bounces+benjamin.segovia=intel....@lists.freedesktop.org
[mesa-dev-bounces+benjamin.segovia=intel....@lists.freedesktop.org] On
Behalf Of Segovia, Benjamin [benjamin.sego...@intel.com]
>> Sent: Tuesday, July 13, 2010 4:11 PM
>> To: mesa-dev@lists.freedesktop.org
>> Subject: [Mesa-dev] Optimizations in mesa shader compiler
>>
>> Hello all,
>>
>> I just looked at the (intermediate) code produced by the shader
compiler. In the last version, I did not find anything on constant
propagation and constant computations. In the Intel current driver,
the final gen code produces an ugly sequence of computations of
constant values (known at compile time). I would like to spend some
time on it but I am wondering if it is still supported or if other
shader compilers are going to replace it.
>
>
> Hi Ben,
>
> The current Mesa GLSL compiler (slang) does some constant expression
> simplification, but not sin, cos, etc. The code in question is in the
> slang_simplify.c file if you want to take a look.
>
> In the mean time, Eric Anholt and Ian Romanick of Intel are working on
> a new compiler for Mesa. See the glsl2 branch in git. Maybe Ian or
> Eric can comment on this area of their compiler. Or maybe you can
> jump in and help them with the new code.
>
> -Brian
>
>
> .
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
.
