On Sat, Apr 3, 2010 at 3:10 PM, Zack Rusin <za...@vmware.com> wrote: > On Saturday 03 April 2010 17:17:46 Luca Barbieri wrote: >> <snipped walls of text> > > From the compute support LLVM->TGSI translation isn't even about > optimizations, it's about "working". Writing a full C/C++ compiler that > generates TGSI is a lot less realistic than reusing Clang and writing a TGSI > code-generator for it. > So the LLVM code-generator for TGSI would be a very high impact project for > 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). > > 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 ) > > 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.
Agreed. There are some things here that need to be kept in mind: 1) r300/r500 are not architectures powerful enough to merit general compilation, and they don't mesh well with LLVM. The hand-written optimizations we already have in place are fine for these chipsets. 2) We should leverage LLVM when possible, since we're going to be increasingly dependent on it anyway. 3) Common code goes up, specialized code goes down. That's the entire point of Gallium. Specialized compiler passes that operate on TGSI but are only consumed by one driver should move down into the driver. I think that the first two parts of Tom's original proposal would be better spent on r300 only, taking nha's r300g-glsl work and cleaning and perfecting it. If we can pass all of the GLSL tests (save for the NOISE test) on r300, then we will be far better off as opposed to work on TGSI towards the same goal. ~ 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
