Am 26.08.2014 um 03:54 schrieb Rob Clark:
On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke <kenn...@whitecape.org> wrote:
we've already had problems where distros refused to ship newer Mesa
releases because radeon depended on a version of LLVM newer than the
one they were shipping, [...]
That's news to me, can you be more specific?
That sounds like basically a distro issue though, since different LLVM
versions can be installed in parallel (and the one used by default
doesn't have to be the newest one). And it even works if another part of
the same process uses a different version of LLVM.
Yes, one can argue that it's a distribution issue - but it's an extremely
painful problem for distributions.
For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to
2014-03-22), and I was told this was because of LLVM versioning changes in the
other drivers (primarily radeon, I believe, but probably also llvmpipe).
Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed that in
Mesa 9.2.3. But we couldn't get people to actually ship it, and had to field
tons of bug reports from upset users for several months.
Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo Mesa
package mantainer) can probably comment more.
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.
Those are the sorts of things I'd like to avoid. The compiler is easily the
most crucial part of a modern graphics stack; splitting it out into a separate
repository and project seems like a nightmare for people who care about getting
new drivers released and shipped in distributions in a timely fashion.
Or, looking at it the other way: today, everything you need as an Intel or
(AFAIK) Nouveau 3D user is nicely contained within Mesa. Our community has
complete control over when we do those releases. New important bug fixes,
performance improvements, or features? Ship a new Mesa, and you're done.
That's a really nice feature I'd hate to lose.
tbh, it sounds a lot to me like if we start using LLVM more
heavily/widely in mesa we should import LLVM (or at least the parts we
need) into the mesa src tree.. as it is, the logistical/distro issues
of LLVM have been what has scared me off the most about using it.
Yes, agree totally. But I think we would always have that problem if we
want to use a compiler infrastructure outside of mesa.
Basically I see only two options:
a) We do everything inside Mesa and so also need to maintain and develop
it further by ourself.
b) We use a compiler infrastructure outside of Mesa with the well known
problems and advantages.
Also what closed source drivers usually do is pulling a certain LLVM
version into their code and so build the compiler infrastructure
directly into their binaries. This obviously isn't such a good idea for
distributions who seems to be concerned about the size of the resulting
binaries, but completely avoids the version clash.
But as far as I can see this could be avoid by maintaining both shared
and static ways of compiling LLVM into Mesa.
Using shared LLVM would mean that LLVM must be installed in one of the
supported versions to use the resulting drivers. Using static LLVM can
be used for somebody who just wants to build the drivers manually. We
could even provide an option to download the necessary LLVM code,
compile it locally and use it only for Mesa.
Regards,
Christian.
BR,
-R
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
