On Fri, 2009-07-24 at 11:35 -0700, Zack Rusin wrote: > On Friday 24 July 2009 14:21:35 José Fonseca wrote: > > But in this step 1 you don't plan to embed the vector width and AoS vs > > Soa in TGSI, right? > > No, nothing changes at that layer. > Essentially LLVM is completely invisible to drivers and TGSI representation > stays exactly the same. > Everything is the same but the TGSI code that comes from GLSL or OpenCL C is > highly optimized. > > The software driver is obviously the special case here because that one > already has a very good hardware LLVM driver (x86 code-generator). And for > softpipe step 1 is of little importance because softpipe is incredibly slow > executing fragment shaders with 5 instructions so the fact that complicated > shaders will have 20 instead of 100 instructions is of little practical > significance there ("this app is running at 0.9fps instead of 0.1fps > now!!!"). > Which means that you could short-circuit to step #2. But that really is a > separate problem that needs a separate project (aka. "making softpipe fast" > project).
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. Keith ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev