[Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
Tom Stellard
tom at stellard.net
Wed Aug 20 12:28:59 PDT 2014
On Wed, Aug 20, 2014 at 11:56:32AM -0700, Matt Turner wrote:
> On Wed, Aug 20, 2014 at 11:13 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> > Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo Mesa package mantainer) can probably comment more.
>
> Yes, at one point we were stuck two releases behind current Mesa (and
> this is Gentoo!) because we couldn't get the appropriate version of
> LLVM stabilized because a number of reverse dependencies didn't work
> with the new LLVM version.
>
> Having multiple versions installed in parallel breaks down pretty
> easily. Where do the headers go? Where do all the executables go? Do
> you version all of them and install one for each version? Do other
> distros allow multiple versions of LLVM to be installed in parallel?
> How do they manage?
>
On one of my (gentoo) dev systems, I have 8 different versions of LLVM installed.
All I do is install each version to a different prefix. For example:
/usr/local/llvm/3.6/
/usr/local/llvm/3.5/
When I build a project like mesa which depends on LLVM, I just point it
to the prefix of the LLVM version that I want to use. Would distros be
able to do something like this?
> > I've also heard stories from friends of mine who use radeonsi that they couldn't get new GL features or compiler fixes unless they upgrade both Mesa /and/ LLVM, and that LLVM was usually either not released or not available in their distribution for a few months.
>
> I get the sense that this is a problem that a backend in LLVM would
> cause, but maybe not so if we just used LLVM IR for the GLSL compiler.
> I think the C API is suitable for this kind of thing as well. Tom?
Yes, see my reply to Ken, but basically using LLVM IR for just GLSL
would require a much smaller subset of LLVM features, most of which
are pretty stable. It would even be using less features than
what llvmpipe uses and llvmpipe still works with older LLVM versions.
-Tom
More information about the mesa-dev
mailing list