On Saturday 03 April 2010 19:07:59 Luca Barbieri wrote: > > 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.
k, that's good. > > 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)_Specif > >ication_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. Which of course means you have to have that reduced scope and well defined constraints that I mentioned. Otherwise it's gonna be impossible to judge the success of the project. > 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. Yes, that's all fine, just like the above it would simply have to be defined, e.g. no texture sampling (since for that stuff we'd obviously want our intrinsics) and whatever other features that go with it. > 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. OpenCL has no need for for TGSI->LLVM translation. It deals only with LLVM IR inside. > So basically the r300 optimization work looks doomed from the > beginning to be eventually obsoleted. Well, if that was the attitude we'd never get anything done, in 10 years the work we're doing right will be obsoleted, in 50 Gallium in general will be probably obsoleted and in 100 we'll be dead (except me, I decided that I'll live forever and so far so good), so what's the point? Writing something simple well, is still a lot better, than writing something hard badly. The point of GSOC is not to nail your first Nobel prize, it's to contribute to a Free Software project and ideally keep you interested so that you keep contributing. Picking insanely hard projects is counter productive even if technically they do make sense. Just like for a GSOC for a Linux kernel you'd suggest someone improves Ext4 rather than write a whole new file system even if long term you'll want something better than Ext4 anyway. Or at least that's what I'd suggest, but that's probably because, in general, I'm just not into sadism. z ------------------------------------------------------------------------------ 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
