[Mesa-dev] RFC: r300 compiler loop emulation

Brian Paul brianp at vmware.com
Wed Jun 9 06:51:13 PDT 2010


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.

-Brian


More information about the mesa-dev mailing list