> Gallium. Obviously a code-generator that can handle control-flow (to be honest > I'm really not sure why you want to restrict it to something without control- > flow in the first place).
The no-control-flow was just for the first step, with a second step supporting everything. > Having said that I'm not sure whether this is something that's a good GSOC > project. It's a fairly difficult piece of code to write. One that to do right > will depend on adding some features to TGSI (a good source of inspiration for > those would be AMD's CAL and NVIDIA's PTX > http://developer.amd.com/gpu_assets/ATI_Intermediate_Language_(IL)_Specification_v2b.pdf > http://www.nvidia.com/content/CUDA-ptx_isa_1.4.pdf ) This would be required to handle arbitrary LLVM code (e.g. for clang/OpenCL use), but since GLSL shader code starts as TGSI, it should be possible to convert it back without TGSI. > I thought the initial proposal was likely a lot more feasible for a GSOC (of > course there one has to point out that Mesa's GLSL compiler already does > unroll loops and in general simplifies control-flow so the points #1 and #2 > are > largely no-ops, but surely there's enough work on Gallium Radeon's drivers > left to keep Tom busy). Otherwise having a well-defined and reduced scope with > clear deliverables would be rather necessary for LLVM->TGSI code because that > is not something that you could get rock solid over a summer. I'd say, as an initial step, restricting to code produced by TGSI->LLVM (AoS) that can be expressed with no intrinsics, having a single basic block, with no optimization passes having been run on it. All 4 restrictions (from TGSI->LLVM, no instrinsics, single BB and no optimizations) can then be lifted in successive iterations. Of course, yes, it has a different scope than the original proposal. The problem I see is that since OpenCL will be hopefully done at some point, then as you say TGSI->LLVM will also be done, and that will probably make any other optimization work irrelevant. So basically the r300 optimization work looks doomed from the beginning to be eventually obsoleted. That said, you may want to do it anyway. But if you really want a quick fix for r300, seriously, just use the nVidia Cg compiler. It's closed source, but being produced by the nVidia team, you can generally rely on it not sucking. It takes GLSL input and spits out optimized ARB_fragment_program (or optionally other languages) so it is trivial to interface with it. It could even be useful to compare the output/performance of that with a more serious LLVM-based solution, to make sure we get the latter right. For instance, personally, I did work on the nv30/nv40 shader assembler (note the word "assembler" here), and haven't done anything more than simple local transforms, for exactly this reason. The only thing I've done for LLVM->TGSI is trying to recover Stephane Marchesin's work on LLVM (forgot to CC him too), lost in an hard drive crash, but failed to find anyone having pulled it. ------------------------------------------------------------------------------ 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
