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
