On Sun, 2009-07-26 at 17:35 -0700, Jose Fonseca wrote:
> 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.
I've done a bit of spare-time work also on re-organizing the code to
reflect the entities which should become units of code-generation. I'll
push that sometime today.
Keith
------------------------------------------------------------------------------
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
