[LLVMdev] [Mesa3d-dev] Folding vector instructions
Zack Rusin
zackr at vmware.com
Thu Jan 1 11:14:13 PST 2009
On Wednesday 31 December 2008 09:15:09 Alex wrote:
> Zack Rusin wrote:
> > I think Alex was referring here to a AOS layout which is completely not
> > ready.
> > Actually currently the plan is to have essentially a "two pass" LLVM IR.
> > I wanted the first one to never lower any of the GPU instructions so we'd
> > have intrinsics or maybe even just function calls like gallium.lit,
> > gallium.dot, gallium.noise and such. Then gallium should query the driver
> > to figure out which instructions the GPU supports and runs our custom
> > llvm lowering pass that decomposes those into things the GPU supports.
>
> If I understand correct, that is to say, the gallium will dynamically build
> a lowering pass by querying the capability (instructions supported by the
> GPU)? Instead, isn't it a better approach to have a lowering pass for each
> GPU and gallium simply uses it?
The whole point of Gallium is to make driver development as simple as
possible. So while it's certainly harder to write this code in a way that
could be generic it's essentially what Gallium is all about and it's at least
worth a try.
> What do you plan to do with SOA and AOS paths in the gallium?
For now we need to figure out whether we need all the layouts or whether one
is enough for all the backends.
> (1) Will they eventually be developed independently? So that for a
> scalar/SIMD GPU, the SOA will be used to generate LLVM IR, and for a vector
> GPU, AOS is used?
Well, they're all connected, so developing them independently would be hard.
As mentioned above, depending on what's going to happen either we'll let the
drivers ask for the layout that they want to work with or decide to use one
layout everywhere.
> (2) At present the difference between SOA and AOS path is not only the
> layout of the input data. The AOS seems to be more complete for me, though
> Rusin has said that it's completely not ready and not used in the gallium.
> Is there a plan to merge/add the support of function/branch and LLVM IR
> extract/insert/shuffle to the SOA code?
I wrote both so I can tell you they're both far from usable. It looks like
Stephane and Corbin are rocking right now but the infrastructure code in
Gallium needs a lot of love. We have a lot of choices to make over the next
few months and obviously all the paths (assuming those will be "paths" and not
a "path") will require feature parity.
> By the way, is there any open source frontend which converts GLSL to LLVM
> IR?
Yes, there is at:
http://cgit.freedesktop.org/~zack/mesa.git.old/log/?h=llvm
but it's also not complete.
z
More information about the llvm-dev
mailing list