[Mesa-dev] RFC: r300 compiler loop emulation

[Jakob Bornecrantz]

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/

Cheers Jakob.