[Mesa-dev] RFC: r300 compiler loop emulation

[Brian Paul]

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?

-Brian