On Sat, Apr 3, 2010 at 3:31 PM, Tom Stellard <tstel...@gmail.com> wrote: > Hi, > > I have completed a first draft of my Google Summer of Code > proposal, and I would appreciate feedback from some of the > Mesa developers. I have included the project plan from my > proposal in this email, and you can also view my full proposal here: > http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/tstellar/t126997450856 > However, I think you will need a google login to view it. > > Project Tasks: > > 1. Enable branch emulation for Gallium drivers: > The goal of this task will be to create an optional "optimization" pass > over the TGSI code to translate branch instructions into instructions > that are supported by cards without hardware branching. The basic > strategy for doing this translation will be: > > A. Copy values of in scope variables > to a temporary location before executing the conditional statement. > > B. Execute the "if true" branch. > > C. Test the conditional expression. If it evaluates to false, rollback > all values that were modified in the "if true" branch. > > D. Repeat step 2 with the "if false" branch, and then step 3, but this > time only rollback if the conditional expression evaluates to true. > > The TGSI instructions SLT, SNE, SGE, SEQ will be used to test the > conditional expression and the instruction CND will be used to rollback > the values. > > There will be two phases to this task. For phase 1, I will implement a > simple translator that will be able to translate the branch instructions > with only one pass through the TGSI code. This simple translator will > copy all in scope variables to a temporary location before executing the > conditional statement, even if those variables will not not be modified > in either of the branches. > > Phase 2 will add a preliminary pass before to the code translation > pass that will mark variables that might be modified by the conditional > statement. Then, during the translation pass, only the variables that > could potentially be modified inside either of the conditional branches > will be copied before the conditional statement is executed. > > 2. Unroll loops for Gallium drivers: > 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 > will be done in the same "optimization" pass as the branch emulation. > Loops where the number of iterations is 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. > > These first two tasks are important not only for older cards that do not > support hardware branching, but newer cards as well. Driver developers > will not need to use every hardware instruction to compile shaders > with branches and loops, so they could use the branch emulation as a > temporary solution while hardware support for branching and loops is > being worked on. > > 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. More compiler optimizations / other GLSL features: > This is an optional task that will allow me to revisit the work from the > previous tasks and explore doing some optimizations I may have wanted to > do, but were outside the scope of those tasks. If there are no obvious > optimizations to be done, this time could be spent implementing some > other GLSL features for the R300 driver, possible ideas include: > > Adding support for the gl_FrontFacing variable. > Handling varying modifiers like perspective, flat, and centroid. > Improving the GLSL frontend to add support for more language features. > > Schedule / Deliverables: > 1. Enable branch emulation for Gallium drivers (4 weeks) > 2. Unroll loops for Gallium drivers (2 - 3 weeks) > Midterm Evaluation > 3. Loops and Conditionals for R500 fragment and vertex shaders (4 weeks) > 4. More compiler optimizations / other GLSL features (2 weeks) > > Tasks 1-3 will be required for this project. > Task 4 is optional. > > Thank you.
Wow! Looks like you're certainly on the right track and you've been doing your research. I would say that the first two items on your list would be fine as a complete project. TGSI streams are tricky to modify, and you may find that you have to write more and more TGSI-specific code as you dig in. (For example, there are no helpers for strength reduction in TGSI yet.) I'll wait for everybody else to chime in, but it looks good so far. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ 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
