Keith wrote:
> 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.
I couldn't agree more.
I've forked softpipe and commited the LLVM based pixel packing/unpacking code I
was working on, into a new branch, gallium-llvmpipe.
Jose
------------------------------------------------------------------------------
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
