On Fri, 2009-07-24 at 17:00 -0700, Anders Juel Jensen wrote: > Ok, I'll bite. Partly because I think gallium looks like the most fascinating > thing in 3D graphics to date, but also because what I can find on wikipedia, > the various blogs and the tungsten site doesn't really explain things in > terms > clear to "spectator fan boys" like me :P > > On Friday 24 July 2009 21: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. > Does this approach mean that the softpipe will only handle missing > functionality for hardware that is fixed function, and then the > llvm-rasterizer > will do the heavy lifting for "stupid" hardware like i945? > > > 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... > (assuming my above question answers yes) > Is this to say that triangle setup is to be done with fpu instructions, and > then let LLVM express the rasterization with sse[1/2/3] code? Naturally I ask > because I am concerned with efficient register utilization.
What I'm really saying is that all the triangle setup functions are basically the same, and there isn't much need to generate them at runtime. We'd still like to use the best technology (eg sse3) to implement that routine, but we probably only need to do it once. If it turns out that using llvm at runtime is actually the easiest way to get that done, we can do that, but there's no need to. > > 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. > The [at least] three remaining ones being? The four I see are: - the fragment shader - texture sample routines - depth/stencil testing - color combine (blend, logicop, colormask) Each of these is well matched to a gallium constant state object, so the code-generation would hopefully be 1:1 with the lifecycle of those CSO's. Note that I'm assuming that vertex transformation is handled elsewhere (by the draw module) and not a part of the immediate discussion. Keith ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
