Jakob Bornecrantz wrote:
On Wed, Jun 9, 2010 at 3:51 PM, Brian Paul <[email protected]> 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
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
