[Mesa-dev] Proposal for a long-term shader compiler (and IR) architecture
Ian Romanick
idr at freedesktop.org
Mon Oct 18 15:23:27 PDT 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Corbin Simpson wrote:
> The biggest problems I had when trying to write an r300 backend for
> LLVM were largely because of the massively specialized nature of
> pre-Dx10 GPUs, which are closer to DSPs than anything LLVM normally
> targets. In particular, v4f32 is the only kind of register available,
> there's not really any way to spill registers, etc. I suspect nvfx and
> i915 have similar issues although I'll readily admit to not knowing
> the hardware that well.
>
> If we transparently LLVMize all shaders before handing them to pipe
> drivers, and use a low-level IR that retains LLVM's optimizations,
> then I am okay with that. If LLVM can understand enough of the various
> scheduling problems to be worthwhile for the entire shader path, then
> I'm okay with that too. I just don't want yet another intermediate
> layer that doesn't actually improve anything.
I think the real task of this work is whether or not LLVM IR can be
converted back "up" into something that GPU code generators can use. We
did a lot of work in GLSL IR to leave the IR in a form that GPU code
generators can use directly. The goal with the LLVM work would be to
use LLVM to do its optimizations then convert it to a form that a
hardware-specific backend could use to do register allocation, code
generation, and instruction scheduling.
It seems unlikely that drivers will generate code directly from LLVM IR
without a lot of help.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAky8yN4ACgkQX1gOwKyEAw/y8ACfSPWtfnoGYn1nEVfqlWw1OXgn
7eUAn2Jhs9ckIw5qR9Q8clRFdebl+fYx
=fv3T
-----END PGP SIGNATURE-----
More information about the mesa-dev
mailing list