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 > 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. > 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. cu, Nicolai ------------------------------------------------------------------------------ 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
