On Wed, Jul 14, 2010 at 6:14 PM, Segovia, Benjamin <benjamin.sego...@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....@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 > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
