On Wed, 09 Jun 2010 08:01:42 -0600, Brian Paul <[email protected]> wrote: > Jakob Bornecrantz wrote: > > On Wed, Jun 9, 2010 at 3:51 PM, Brian Paul <[email protected]> wrote: > >> Tom Stellard wrote: > >>> On Tue, Jun 08, 2010 at 09:16:06AM -0600, Brian Paul wrote: > >>>> Tom Stellard wrote: > >>>>> On Mon, Jun 07, 2010 at 08:38:15AM -0600, Brian Paul wrote: > >>>>>> Tom Stellard wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I have just published a branch with loop emulation for the r300 > >>>>>>> compiler here: http://cgit.freedesktop.org/~tstellar/mesa/ > >>>>>>> This adds support for unrolling of loops that have a constant number > >>>>>>> of > >>>>>>> iterations (e.g. for(i=0; i<10; i++) or for(i=10; i>0; i--) > >>>>>>> It only handles cases where the counter is either added to or > >>>>>>> subtracted > >>>>>>> from, like the examples above, but I think this covers a majority > >>>>>>> of loops. > >>>>>>> > >>>>>>> Loops that have an unknown number of iterations are unrolled as many > >>>>>>> times as possible without going over the instruction limit for the > >>>>>>> shader program. > >>>>>>> > >>>>>>> Right now, this is only enabled for fragment shaders, but I am working > >>>>>>> on > >>>>>>> enabling it for vertex shaders. > >>>>>>> > >>>>>>> Any comments/suggestions would be appreciated. Thanks. > >>>>>> Is there any advantage to doing this in the r300 compiler instead of > >>>>>> the GLSL compiler? The GLSL compiler already does loop unrolling in > >>>>>> some > >>>>>> cases. If we do it in the GLSL compiler, all the drivers can benefit. > >>>>>> > >>>>> The r300 compiler needs to have very aggressive loop unrolling for the > >>>>> r300 cards that don't have loop instructions. I am not sure if the > >>>>> kind of loop unrolling it is doing would be appropriate for the GLSL > >>>>> compiler in all cases. Although, I think you are right, just like other > >>>>> optimizations any loop unrolling that the GLSL complier can do would be > >>>>> a plus. > >>>> I guess I'd like to see the loop unrolling code be primarily in the GLSL > >>>> compiler. > >>>> > >>>> If the driver needs to give hints to the compiler (such as "always > >>>> unroll" or "never unroll") we can add additional flags to struct > >>>> gl_shader_state. Drivers can set those flags and the compiler will > >>>> follow > >>>> them. > >>> I spent some time looking through the code, and I think in order to do > >>> more advanced loop unrolling, the unroll code will need to be moved out > >>> of the code gen pass and into its own optimization pass. This is doable, > >>> but I think it will take more time than I had planned to spend on > >>> loop unrolling. So for now, I am going to focus on my GSOC tasks, > >>> and I can revisit this when I am done. > >> OK. > >> > >> > >>> P.S. Is GLSL2 going to replace the current mesa frontend at some point? > >>> If so, maybe it won't be very useful to modify the current one. > >> GLSL2? GLSL version 1.4 is the latest version. > > > > The new GLSL compiler that Intel is writing > > http://cgit.freedesktop.org/~anholt/glsl2/ > > I haven't really been following that. How about a status report from > Eric and Ian?
Parser is at 338/363 testcases passing earlier today (way more than Mesa master) without the preprocessor integrated. - I need to get texture intructions into the Mesa IR codegen - glue it into Mesa and test that codegen actually works - More matrix handling in codegen, and whole-matrix/structure assignment. - Memory management needs to be fixed. - cworth's preprocessor needs integration - loop unrolling needs doing - more builtins need runtime testcases - Maybe a couple more tasks I'm forgetting?
pgp281dtVkbbG.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
