[Mesa-dev] RFC: r300 compiler loop emulation

[Eric Anholt]

On Wed, 09 Jun 2010 08:01:42 -0600, Brian Paul <brianp at vmware.com> wrote:
> Jakob Bornecrantz wrote:
> > On Wed, Jun 9, 2010 at 3:51 PM, Brian Paul <brianp at vmware.com> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100609/da6ddbfb/attachment.pgp>