On Friday 24 July 2009 15:40:25 Keith Whitwell wrote: > I think a fast software rasterizer project would be better described as > "create a gallium driver targetting LLVM" (as opposed to optimizing > softpipe), as softpipe fills a pretty useful niche in its current form. > > Thinking of LLVM as "the hardware" has a couple of positive > psychological implications -- most importanly that we are in the > business of programming LLVM to do rasterization, rather than just using > it to provide some niche fastpaths in an otherwise complete software > rasterizer. > > Below a certain level (be it triangle or batch of quads or even vertex > buffer), everything should be handled by LLVM-generated code, in the > same way we would hand off to hardware at a given level... > > There at least four key places where we want to generate code (TGSI > shaders are only one of them), and we want to choose plumbing between > them which is optimal for however llvm turns out to require it -- all of > which means that in such a driver LLVM won't be hidden behind shader > opcodes, but will be completely in the foreground.
Yea, that sounds great, but that all sounds like an argument to remove gallivm from master rather than keep it. Obviously a driver aimed at making LLVM target hardware would be highly desirable for cpus, cell, larrabee and so on, but gallivm doesn't add value to that project right now. If we were to start a project like that then doing TGSI->LLVM IR in the driver instead of through gallivm would be just simpler. It'd be a lot easier and quicker to export that generator once we'd know that it's actually reusable (so doing the design bottom->top, rather than top->down). It's a huge advantage of actually writing a driver that needs a certain functionality, versus writing certain functionality hoping that it will fill a need of a driver in the future (what we've done so far in gallivm). It would mean that gallivm would actually prove to be useful, rather than force it to just be (in its current form at least). So yea, I think ideally we'd just bootstrap a quick and dirty driver and we could move the basic soa code-generation from gallivm to it, remove temporarily gallivm and work on that code in the driver. z ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
