Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
On Thu, 2012-07-26 at 11:35 -0700, Jose Fonseca wrote: > > - Original Message - > > On Thu, 2012-07-26 at 10:31 -0700, Jose Fonseca wrote: > > > - Original Message - > > > > On Thu, 2012-07-26 at 07:52 -0700, Jose Fonseca wrote: > > > > > - Original Message - > > > > > > On 7/21/12 5:53 AM, Jose Fonseca wrote: > > > > > > > - Original Message - > > > > > > >> Hi guys > > > > > > >> > > > > > > >> LLVM 2.8 doesn't appear to have mcjit, so we end up with > > > > > > >> no > > > > > > >> llvm > > > > > > >> libs > > > > > > >> defined, > > > > > > > > > > > > > > Yes, mcjit is only used/necessary from llvm-3.1 onwards, so > > > > > > > the > > > > > > > autoconf code should check conditiionally. > > > > > > > > > > > > > > BTW, I'll soon commit a change that will stop using mcjit > > > > > > > from > > > > > > > 3.2 > > > > > > > onwards (as with the current LLVM 3.2 trunk, AVX is > > > > > > > supported > > > > > > > by > > > > > > > the old jit, which is more stable/polished). > > > > > > > > Can you clarify the scope of "will stop using mcjit from 3.2 > > > > onwards"? > > > > > > What I meant by that was already done in commit > > > c30bf68946433d26f672c741a763bba4712aada7. > > > > > > Is that specific to (the Intel AVX extensions?) related matters, > > > > or > > > > is > > > > that a mesa-wide statement?(I am specifically interested in > > > > the > > > > llvmpipe related parts that Adam touched on below). > > > > > > The MC-JIT vs old JIT is currently a build time choice (based on > > > #ifdef's). Essentially, we only use MC-JIT for LLVM 3.1, if AVX > > > support hasn't been backported (ie. when not using my backports_31 > > > branch below). > > > > Ok. Between the explanation and the commit you mentioned above, it's > > clearer now. Thanks. :-)Additional comment below. > > > > > It could be made into a runtime choice if you prefer, ie., based of > > > the availability of AVX. Or we could just disable MC-JIT > > > altogether, > > > and wait until it replaces the old jit upstream. > > > > Per the "Help with PPC64 JIT" comments on llvm-dev last week, we are > > currently working on MC-JIT, rather than oldJIT (This ultimately in > > support of mesa/llvmpipe functionality on ppc64). Some of the work > > is > > occurring with fedora17 based sources, but most on Trunk/HEAD. (so > > HAVE_LLVM == 0x0302 ). > > > > So would prefer some way to specify that MC-JIT be used. A run-time > > (or > > easy build-time configure option) choice would be nice. > > That's easy: you can just add a #ifdef stanza to that code saying > > #if HAVE_LLVM >= 0x0302 && defined(PIPE_ARCH_PPC) //(or something like it) > # define USE_MCJIT 1 > # define HAVE_AVX 0 > #elif ... > > When you're ready. > > I'll ensure that the current support for MC-JIT doesn't degrade. Sounds good, Thanks! :-) > > Jose > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
- Original Message - > On Thu, 2012-07-26 at 10:31 -0700, Jose Fonseca wrote: > > - Original Message - > > > On Thu, 2012-07-26 at 07:52 -0700, Jose Fonseca wrote: > > > > - Original Message - > > > > > On 7/21/12 5:53 AM, Jose Fonseca wrote: > > > > > > - Original Message - > > > > > >> Hi guys > > > > > >> > > > > > >> LLVM 2.8 doesn't appear to have mcjit, so we end up with > > > > > >> no > > > > > >> llvm > > > > > >> libs > > > > > >> defined, > > > > > > > > > > > > Yes, mcjit is only used/necessary from llvm-3.1 onwards, so > > > > > > the > > > > > > autoconf code should check conditiionally. > > > > > > > > > > > > BTW, I'll soon commit a change that will stop using mcjit > > > > > > from > > > > > > 3.2 > > > > > > onwards (as with the current LLVM 3.2 trunk, AVX is > > > > > > supported > > > > > > by > > > > > > the old jit, which is more stable/polished). > > > > > > Can you clarify the scope of "will stop using mcjit from 3.2 > > > onwards"? > > > > What I meant by that was already done in commit > > c30bf68946433d26f672c741a763bba4712aada7. > > > > Is that specific to (the Intel AVX extensions?) related matters, > > > or > > > is > > > that a mesa-wide statement?(I am specifically interested in > > > the > > > llvmpipe related parts that Adam touched on below). > > > > The MC-JIT vs old JIT is currently a build time choice (based on > > #ifdef's). Essentially, we only use MC-JIT for LLVM 3.1, if AVX > > support hasn't been backported (ie. when not using my backports_31 > > branch below). > > Ok. Between the explanation and the commit you mentioned above, it's > clearer now. Thanks. :-)Additional comment below. > > > It could be made into a runtime choice if you prefer, ie., based of > > the availability of AVX. Or we could just disable MC-JIT > > altogether, > > and wait until it replaces the old jit upstream. > > Per the "Help with PPC64 JIT" comments on llvm-dev last week, we are > currently working on MC-JIT, rather than oldJIT (This ultimately in > support of mesa/llvmpipe functionality on ppc64). Some of the work > is > occurring with fedora17 based sources, but most on Trunk/HEAD. (so > HAVE_LLVM == 0x0302 ). > > So would prefer some way to specify that MC-JIT be used. A run-time > (or > easy build-time configure option) choice would be nice. That's easy: you can just add a #ifdef stanza to that code saying #if HAVE_LLVM >= 0x0302 && defined(PIPE_ARCH_PPC) //(or something like it) # define USE_MCJIT 1 # define HAVE_AVX 0 #elif ... When you're ready. I'll ensure that the current support for MC-JIT doesn't degrade. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
On Thu, 2012-07-26 at 10:31 -0700, Jose Fonseca wrote: > - Original Message - > > On Thu, 2012-07-26 at 07:52 -0700, Jose Fonseca wrote: > > > - Original Message - > > > > On 7/21/12 5:53 AM, Jose Fonseca wrote: > > > > > - Original Message - > > > > >> Hi guys > > > > >> > > > > >> LLVM 2.8 doesn't appear to have mcjit, so we end up with no > > > > >> llvm > > > > >> libs > > > > >> defined, > > > > > > > > > > Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the > > > > > autoconf code should check conditiionally. > > > > > > > > > > BTW, I'll soon commit a change that will stop using mcjit from > > > > > 3.2 > > > > > onwards (as with the current LLVM 3.2 trunk, AVX is supported > > > > > by > > > > > the old jit, which is more stable/polished). > > > > Can you clarify the scope of "will stop using mcjit from 3.2 > > onwards"? > > What I meant by that was already done in commit > c30bf68946433d26f672c741a763bba4712aada7. > > Is that specific to (the Intel AVX extensions?) related matters, or > > is > > that a mesa-wide statement?(I am specifically interested in the > > llvmpipe related parts that Adam touched on below). > > The MC-JIT vs old JIT is currently a build time choice (based on > #ifdef's). Essentially, we only use MC-JIT for LLVM 3.1, if AVX > support hasn't been backported (ie. when not using my backports_31 > branch below). Ok. Between the explanation and the commit you mentioned above, it's clearer now. Thanks. :-)Additional comment below. > It could be made into a runtime choice if you prefer, ie., based of > the availability of AVX. Or we could just disable MC-JIT altogether, > and wait until it replaces the old jit upstream. Per the "Help with PPC64 JIT" comments on llvm-dev last week, we are currently working on MC-JIT, rather than oldJIT (This ultimately in support of mesa/llvmpipe functionality on ppc64). Some of the work is occurring with fedora17 based sources, but most on Trunk/HEAD. (so HAVE_LLVM == 0x0302 ). So would prefer some way to specify that MC-JIT be used. A run-time (or easy build-time configure option) choice would be nice. Thanks, -Will > > BTW, for best results using llvmpipe on 3.1, please consider using > http://cgit.freedesktop.org/~jrfonseca/llvm/log/?h=backports_31 as it > includes some backports of bugs/enhacements that affect llvmpipe to > LLVM 3.1. > > Jose > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
- Original Message - > On Thu, 2012-07-26 at 07:52 -0700, Jose Fonseca wrote: > > - Original Message - > > > On 7/21/12 5:53 AM, Jose Fonseca wrote: > > > > - Original Message - > > > >> Hi guys > > > >> > > > >> LLVM 2.8 doesn't appear to have mcjit, so we end up with no > > > >> llvm > > > >> libs > > > >> defined, > > > > > > > > Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the > > > > autoconf code should check conditiionally. > > > > > > > > BTW, I'll soon commit a change that will stop using mcjit from > > > > 3.2 > > > > onwards (as with the current LLVM 3.2 trunk, AVX is supported > > > > by > > > > the old jit, which is more stable/polished). > > Can you clarify the scope of "will stop using mcjit from 3.2 > onwards"? What I meant by that was already done in commit c30bf68946433d26f672c741a763bba4712aada7. > Is that specific to (the Intel AVX extensions?) related matters, or > is > that a mesa-wide statement?(I am specifically interested in the > llvmpipe related parts that Adam touched on below). The MC-JIT vs old JIT is currently a build time choice (based on #ifdef's). Essentially, we only use MC-JIT for LLVM 3.1, if AVX support hasn't been backported (ie. when not using my backports_31 branch below). It could be made into a runtime choice if you prefer, ie., based of the availability of AVX. Or we could just disable MC-JIT altogether, and wait until it replaces the old jit upstream. BTW, for best results using llvmpipe on 3.1, please consider using http://cgit.freedesktop.org/~jrfonseca/llvm/log/?h=backports_31 as it includes some backports of bugs/enhacements that affect llvmpipe to LLVM 3.1. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
On Thu, 2012-07-26 at 07:52 -0700, Jose Fonseca wrote: > - Original Message - > > On 7/21/12 5:53 AM, Jose Fonseca wrote: > > > - Original Message - > > >> Hi guys > > >> > > >> LLVM 2.8 doesn't appear to have mcjit, so we end up with no llvm > > >> libs > > >> defined, > > > > > > Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the > > > autoconf code should check conditiionally. > > > > > > BTW, I'll soon commit a change that will stop using mcjit from 3.2 > > > onwards (as with the current LLVM 3.2 trunk, AVX is supported by > > > the old jit, which is more stable/polished). Can you clarify the scope of "will stop using mcjit from 3.2 onwards"? Is that specific to (the Intel AVX extensions?) related matters, or is that a mesa-wide statement?(I am specifically interested in the llvmpipe related parts that Adam touched on below). Thanks, -Will > > > > Is there a long-term plan or theory for which jit we'll be using? > > Are we just following upstream? > > I see ourselves foremost as consumers of LLVM, so the default answer is: to > follow upstream, unless it does not fit our purposes. > > > Are the problems of mcjit simply a superset > > of the problems with the old jit? > > The only reason we started to look at mcjit was because old jit didn't > support avx. But on current trunk (ie llvm-3.2) it does. > > To be honest, apart of avx, none of the benefits of mcjit matter to me: > - we're not compiling from a C source file (or any kind of source file), so > not sure what GDB integration will bring > and all its shortcomings affect me > - each engine can only compile one module -- huge memory waste > - there are redundant version of the code -- more memory waste > - half baked ELF support > - does not support windows > > IMO, mcjit it's not production quality, and progress has been awfully slow. > > > I know there are people interested in supporting other arches in > > llvmpipe, so it'd be nice if they knew what to work on. And > > personally > > the gdb integration bit of mcjit sounds really appealing from a > > support > > perspective. > > llvmpipe currently can support both, so it's really their choice. > > Jose > ___ > 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
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
- Original Message - > On 7/26/12 10:52 AM, Jose Fonseca wrote: > > - Original Message - > >> Are the problems of mcjit simply a superset > >> of the problems with the old jit? > > > > The only reason we started to look at mcjit was because old jit > > didn't support avx. But on current trunk (ie llvm-3.2) it does. > > > > To be honest, apart of avx, none of the benefits of mcjit matter to > > me: > > - we're not compiling from a C source file (or any kind of source > > file), so not sure what GDB integration will bring > > and all its shortcomings affect me > > I don't think this is essentially true, just temporally true. > Imagine a > consumer more like OpenCL than OpenGL. Or, imagine being able to > breakpoint and single-step in your GL shaders to see where something > complicated goes wrong. hmm. It would require that GLSL and TGSI preserved debug info. But I can now see the benefit of tight gdb integration in such case. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
On 7/26/12 10:52 AM, Jose Fonseca wrote: - Original Message - Are the problems of mcjit simply a superset of the problems with the old jit? The only reason we started to look at mcjit was because old jit didn't support avx. But on current trunk (ie llvm-3.2) it does. To be honest, apart of avx, none of the benefits of mcjit matter to me: - we're not compiling from a C source file (or any kind of source file), so not sure what GDB integration will bring and all its shortcomings affect me I don't think this is essentially true, just temporally true. Imagine a consumer more like OpenCL than OpenGL. Or, imagine being able to breakpoint and single-step in your GL shaders to see where something complicated goes wrong. IMO, mcjit it's not production quality, and progress has been awfully slow. That sounds decisive enough for me, thanks. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
- Original Message - > On 7/21/12 5:53 AM, Jose Fonseca wrote: > > - Original Message - > >> Hi guys > >> > >> LLVM 2.8 doesn't appear to have mcjit, so we end up with no llvm > >> libs > >> defined, > > > > Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the > > autoconf code should check conditiionally. > > > > BTW, I'll soon commit a change that will stop using mcjit from 3.2 > > onwards (as with the current LLVM 3.2 trunk, AVX is supported by > > the old jit, which is more stable/polished). > > Is there a long-term plan or theory for which jit we'll be using? > Are we just following upstream? I see ourselves foremost as consumers of LLVM, so the default answer is: to follow upstream, unless it does not fit our purposes. > Are the problems of mcjit simply a superset > of the problems with the old jit? The only reason we started to look at mcjit was because old jit didn't support avx. But on current trunk (ie llvm-3.2) it does. To be honest, apart of avx, none of the benefits of mcjit matter to me: - we're not compiling from a C source file (or any kind of source file), so not sure what GDB integration will bring and all its shortcomings affect me - each engine can only compile one module -- huge memory waste - there are redundant version of the code -- more memory waste - half baked ELF support - does not support windows IMO, mcjit it's not production quality, and progress has been awfully slow. > I know there are people interested in supporting other arches in > llvmpipe, so it'd be nice if they knew what to work on. And > personally > the gdb integration bit of mcjit sounds really appealing from a > support > perspective. llvmpipe currently can support both, so it's really their choice. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
On 7/21/12 5:53 AM, Jose Fonseca wrote: - Original Message - Hi guys LLVM 2.8 doesn't appear to have mcjit, so we end up with no llvm libs defined, Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the autoconf code should check conditiionally. BTW, I'll soon commit a change that will stop using mcjit from 3.2 onwards (as with the current LLVM 3.2 trunk, AVX is supported by the old jit, which is more stable/polished). Is there a long-term plan or theory for which jit we'll be using? Are we just following upstream? Are the problems of mcjit simply a superset of the problems with the old jit? I know there are people interested in supporting other arches in llvmpipe, so it'd be nice if they knew what to work on. And personally the gdb integration bit of mcjit sounds really appealing from a support perspective. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
I went ahead and pushed it. Hopefully it should fix it. Jose - Original Message - > The attached patch should fix, but I don't have a machine with old > llvm now. > > Jose > > - Original Message - > > - Original Message - > > > Hi guys > > > > > > LLVM 2.8 doesn't appear to have mcjit, so we end up with no llvm > > > libs > > > defined, > > > > Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the > > autoconf code should check conditiionally. > > > > BTW, I'll soon commit a change that will stop using mcjit from 3.2 > > onwards (as with the current LLVM 3.2 trunk, AVX is supported by > > the > > old jit, which is more stable/polished). > > > > > look at the recent build failures in tinderbox.x.org. > > > > Interesting. Where can I read more about tinderbox.x.org setup? > > Would > > it be possible to add our own machines to the mix? > > > > I'm maintaining builds on a Jenkins machine internally. I'd like to > > provide Mesa/piglit build results for platforms we care that few > > other developers use (i.e., windows), but the jenkins server is > > also > > building/testing internal projects, and I don't really have the > > time > > to maintain a separate public-facing jenkins server. But the load > > of > > mainting a slave build machine for tinderbox.x.org sounds feasible. > > > > Jose > > ___ > > 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
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
- Original Message - > > Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the > > autoconf code should check conditiionally. > > > > BTW, I'll soon commit a change that will stop using mcjit from 3.2 > > onwards (as with the current LLVM 3.2 trunk, AVX is supported by > > the old jit, which is more stable/polished). > > > >> look at the recent build failures in tinderbox.x.org. > > > > Interesting. Where can I read more about tinderbox.x.org setup? > > Would it be possible to add our own machines to the mix? > > http://www.x.org/wiki/Tinderbox > > has all the instructions for adding a machine, > > I just run the RHEL6 one in a VM on a server, doesn't take much > looking after. Thanks. At a glance, it sounds that setup jhbuild to build for native windows (as opposed to cygwin) might pose some challenges. But I'll look into it. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
The attached patch should fix, but I don't have a machine with old llvm now.
Jose
- Original Message -
> - Original Message -
> > Hi guys
> >
> > LLVM 2.8 doesn't appear to have mcjit, so we end up with no llvm
> > libs
> > defined,
>
> Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the
> autoconf code should check conditiionally.
>
> BTW, I'll soon commit a change that will stop using mcjit from 3.2
> onwards (as with the current LLVM 3.2 trunk, AVX is supported by the
> old jit, which is more stable/polished).
>
> > look at the recent build failures in tinderbox.x.org.
>
> Interesting. Where can I read more about tinderbox.x.org setup? Would
> it be possible to add our own machines to the mix?
>
> I'm maintaining builds on a Jenkins machine internally. I'd like to
> provide Mesa/piglit build results for platforms we care that few
> other developers use (i.e., windows), but the jenkins server is also
> building/testing internal projects, and I don't really have the time
> to maintain a separate public-facing jenkins server. But the load of
> mainting a slave build machine for tinderbox.x.org sounds feasible.
>
> Jose
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
diff --git a/configure.ac b/configure.ac
index 1d60957..7b88331 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1847,10 +1847,14 @@ if test "x$enable_gallium_llvm" = xyes; then
dnl We can't use $LLVM_VERSION because it has 'svn' stripped out,
LLVM_LIBS="-lLLVM-`$LLVM_CONFIG --version`"
else
- LLVM_LIBS="`$LLVM_CONFIG --libs engine bitwriter mcjit`"
+LLVM_COMPONENTS="engine bitwriter"
+if $LLVM_CONFIG --components | grep -q '\'; then
+LLVM_COMPONENTS="${LLVM_COMPONENTS} mcjit"
+fi
if test "x$enable_opencl" = xyes; then
-LLVM_LIBS="${LLVM_LIBS} `$LLVM_CONFIG --libs ipo linker instrumentation`"
+LLVM_COMPONENTS="${LLVM_COMPONENTS} ipo linker instrumentation"
fi
+LLVM_LIBS="`$LLVM_CONFIG --libs ${LLVM_COMPONENTS}`"
fi
LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
LLVM_BINDIR=`$LLVM_CONFIG --bindir`
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
> Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the autoconf code > should check conditiionally. > > BTW, I'll soon commit a change that will stop using mcjit from 3.2 onwards > (as with the current LLVM 3.2 trunk, AVX is supported by the old jit, which > is more stable/polished). > >> look at the recent build failures in tinderbox.x.org. > > Interesting. Where can I read more about tinderbox.x.org setup? Would it be > possible to add our own machines to the mix? http://www.x.org/wiki/Tinderbox has all the instructions for adding a machine, I just run the RHEL6 one in a VM on a server, doesn't take much looking after. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] 761131ce4591e5f55f38d13f2c4d2194bc9cb0fd build regression with llvm 2.8
- Original Message - > Hi guys > > LLVM 2.8 doesn't appear to have mcjit, so we end up with no llvm libs > defined, Yes, mcjit is only used/necessary from llvm-3.1 onwards, so the autoconf code should check conditiionally. BTW, I'll soon commit a change that will stop using mcjit from 3.2 onwards (as with the current LLVM 3.2 trunk, AVX is supported by the old jit, which is more stable/polished). > look at the recent build failures in tinderbox.x.org. Interesting. Where can I read more about tinderbox.x.org setup? Would it be possible to add our own machines to the mix? I'm maintaining builds on a Jenkins machine internally. I'd like to provide Mesa/piglit build results for platforms we care that few other developers use (i.e., windows), but the jenkins server is also building/testing internal projects, and I don't really have the time to maintain a separate public-facing jenkins server. But the load of mainting a slave build machine for tinderbox.x.org sounds feasible. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
