On Mon, Apr 05, 2010 at 11:18:39AM -0400, Nicolai Haehnle wrote: > Hi, > > On Mon, Apr 5, 2010 at 1:58 AM, Tom Stellard <tstel...@gmail.com> wrote: > > 1. Improve branch emulation in the r300 compiler: > > The goal of this task will be to improve upon the work done by > > Nicolai Häehnle in this branch: > > http://cgit.freedesktop.org/~nh/mesa/log/?h=r300g-glsl and fully support > > branch emulation in the r300 compiler. This first part of this task > > will involve testing the current branch emulation code to determine what > > works and what does not. After this has been completed work can begin > > on any part of the branch emulation that does not work correctly. > > You misspelled my name :P > Oops. Sorry. How do you spell your name? Your git commits say Nicolai Hähnle, but your email says Nicolai Haehnle.
> > 2. Unroll loops in the r300 compiler: > > The goal of this task will be to unroll loops so that they can be executed > > by hardware that does not support them. The loop unrolling in this task > > is not meant as a code optimization. It is only being done to eliminate > > branch instructions. Loops where the number of iterations are known > > at compile time will be unrolled and may have additional optimizations > > applied. Loops that have an unknown number of iterations, will have to > > be studied to see if there is a way to replace the loop with a set of > > instructions that produces the same output as the loop. For example, > > one solution might be to replace an ADD(src0, src0) instruction that > > is supposed to execute n times with a MUL(src0, n). It is possible that > > not all loops will be able to be unrolled successfully. > > It is certain that not all loops will be able to be unrolled > successfully, if only due to limits on the number of instruction in a > shader ;) > > For loops with number of iterations determined at runtime, you should > check (ask around) for real-life shaders where this is the case. The > example you mention sounds unrealistic to me, but I could imagine that > there are shaders with an *upper-bound* on the number of iterations > known at compile time. Then loops can be unrolled to that upper-bound, > and later iterations could be masked off somehow based on the actual > desired number of iterations at runtime. > > Also note that early GLSL revision actually have some very strict > limits on the kinds of loops the shaders can contain there. > Ok, I'll look into this a little bit more, and see what I can find out. > > 3. Loops and Conditionals for R500 fragment and vertex shaders: The > > goal of this task will be to make use of the R500 hardware support for > > branches and loops. New radeon_compiler opcodes (RC_OPCODE_*) will need > > to be added to represent loops, and the corresponding TGSI instructions > > will need to be converted into these new opcodes during the TGSI_OPCODE_* > > to RC_OPCODE_* phase. Once this has been done, the code generator for > > R500 vertex and fragment shaders will need to be modified to output the > > correct hardware instructions for loops. > > > > 4. Optional Tasks: > > Here is a list of things that could be explored if there is some extra > > time left at the end of the project. > > > > a) Using r300 compiler for branch emulation/loop unrolling in Gallium > > drivers: > > The goal of this task would be to apply branch emulation and loop > > unrolling to TGSI code. This would be accomplished by creating a Gallium > > util function that takes TGSI code, converts it to the r300 compiler > > intermediate language(RC) and then uses the r300 compiler to do the > > branch emulation and loop unrolling. The RC would then be converted > > back into TGSI and passed back to the driver calling the function. > > I think you should highlight that the point of this exercise is that > drivers for *other* hardware might want to use this functionality. > Thanks for you input. -Tom Stellard ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
