[Mesa-dev] RFC: r300 compiler loop emulation

Jakob Bornecrantz wallbraker at gmail.com
Wed Jun 9 06:53:55 PDT 2010

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

Cheers Jakob.

More information about the mesa-dev mailing list