[Mesa-dev] Optimizations in mesa shader compiler
Segovia, Benjamin
benjamin.segovia at intel.com
Wed Jul 14 21:16:15 PDT 2010
Thanks for that. It may be clearly useful.
FYW, I output big shaders from nexuiz (> 100 inst) and clearly swizzling kills opportunities of optimizations. A serie of instructions may be totally useless but swizzles make the flow analysis more complicated.
For big nexuiz fragment shaders, almost all the moves may be removed. This may lead to remove almost 40% of the instructions in these cases.
I am not sure of the final speed up at the end. Intel GPUs use SoA computations for the fragment programs. So, it should be easy to completely remove the swizzle and to consider everything scalar. In that case, flow analysis becomes easier.
However, despite that, the Intel Gen output still includes uncessary moves in particular from GPR to message registers. Not sure it is still related.
Hmmm. Cool. We may be able anyway to make it faster :)
Ben
________________________________________
From: Alex Deucher [alexdeucher at gmail.com]
Sent: Wednesday, July 14, 2010 4:20 PM
To: Segovia, Benjamin
Cc: Brian Paul; mesa-dev at lists.freedesktop.org
Subject: Re: [Mesa-dev] Optimizations in mesa shader compiler
On Wed, Jul 14, 2010 at 6:14 PM, Segovia, Benjamin
<benjamin.segovia at intel.com> wrote:
> Hmmm, (partial) error from my side.
>
> Despite the code posted in the first post, the initial code was _without_ consting the variables. The code _without_ "const" leads to the GPU code with the arithmetic computations on constant.
> Adding the const keyword simplifies the expressions (and let the sin/cos as you said).
>
> Re-reading the code from _slang_compile/_slang_codegen..., it however seems that we are limited to specific optimizations here and the front end is not capable to do any optimizations without the proper hint on the variable.
>
> I am so wondering if mostly working on the gpu code is not the simpler solution.
>
> What are you guys from glsl2 project your strategy? I just read that the compiler will output GPU code. Are you planning extensive optimizations on your side or so you want to rely on mesa optimizations (_mesa_optimize, _mesa_remove_moves...)
>
FWIW, the shader compiler in the r300 driver has some useful
optimizations that could be used elsewhere:
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/compiler
Alex
> Cheers,
> Ben
>
>
> ________________________________________
> From: mesa-dev-bounces+benjamin.segovia=intel.com at lists.freedesktop.org [mesa-dev-bounces+benjamin.segovia=intel.com at lists.freedesktop.org] On Behalf Of Segovia, Benjamin [benjamin.segovia at intel.com]
> Sent: Wednesday, July 14, 2010 3:15 PM
> To: Brian Paul
> Cc: mesa-dev at 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 [brianp at vmware.com]
> Sent: Wednesday, July 14, 2010 12:54 PM
> To: Segovia, Benjamin
> Cc: mesa-dev at 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 [brianp at vmware.com]
> > Sent: Wednesday, July 14, 2010 7:54 AM
> > To: Segovia, Benjamin
> > Cc: mesa-dev at 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.com at lists.freedesktop.org
> [mesa-dev-bounces+benjamin.segovia=intel.com at lists.freedesktop.org] On
> Behalf Of Segovia, Benjamin [benjamin.segovia at intel.com]
> >> Sent: Tuesday, July 13, 2010 4:11 PM
> >> To: mesa-dev at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
More information about the mesa-dev
mailing list