Re: [Mesa-dev] [PATCH 7/8] util: Expand the comment above the channel[] array
On Thu, 2013-06-13 at 14:50 +0100, Richard Sandiford wrote: > The entirety of the comment looks pretty good to me. :-) One question, and this is mostly curiosity on my part, I'm not specifically asking for another revision. > * (This is the same as C bitfield layout on most ABIs.) Do we have a handle on what 'most ABIs' are? I.e. would this include X86* and PPC* ABIs as we know them today, or do we already clearly understand which ones would not match? Thanks, -Will ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] powerpc / gallium/drivers/llvmpipe segfaults running lp_test_* tests
Hi, I'm starting to investigate mesa/llvmpipe on powerpc (powerpc64/power7) and hitting some issues trying to run the tests found in mesa/src/gallium/drivers/llvmpipe/lp_test_*. (lp_test_arit, lp_test_printf, lp_test_blend all seem to fail in similar fashion. lp_test_round passes, but does not provide any output, so I'm not sure it's actually doing anything. ) I'll note that I'm still ramping up on my understanding of all the parts, don't quite know what I'm doing yet, and will not be surprised if this involves user error. pointers and tips on what I should tweak/poke/kick next are appreciated. :-) Configure and build are on a fedora 17 based power7 box, using mesa .git HEAD as of today. [willschm@fuzzy mesa]$ ./autogen.sh --enable-gallium-llvm < build steps trimmed > [willschm@fuzzy mesa]$ cd src/gallium/drivers/llvmpipe [willschm@fuzzy llvmpipe]$ ./lp_test_printf Segmentation fault [willschm@fuzzy llvmpipe]$ file ./lp_test_printf ./lp_test_printf: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xb372fe4bb8536c54a3ac70df31537516ec7b8d2d, not stripped build incantation for lp_test_printf looks like so: g++ -L/usr/lib64/llvm -lpthread -lffi -ldl -lm lp_test_printf.o lp_test_main.o -o lp_test_printf -Wl,--start-group -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVMBitWriter -lLLVMPowerPCCodeGen -lLLVMSelectionDAG -lLLVMPowerPCDesc -lLLVMAsmPrinter -lLLVMMCParser -lLLVMPowerPCAsmPrinter -lLLVMPowerPCInfo -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm -ldrm -lm -lpthread -ldl -Wl,--end-group A bit of time inside gdb: Reading symbols from /home/willschm/llvm/mesa/src/gallium/drivers/llvmpipe/lp_test_printf...done. (gdb) r Starting program: /home/willschm/llvm/mesa/src/gallium/drivers/llvmpipe/lp_test_printf [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x7c0802a6f8010010 in ?? () (gdb) bt #0 0x7c0802a6f8010010 in ?? () #1 0x1001df40 in test_printf (gallivm=0x10a11e80, testcase=, fp=, verbose=) at lp_test_printf.c:112 #2 0x1001e040 in test_all (fp=, verbose=, gallivm=) at lp_test_printf.c:125 #3 test_some (gallivm=, verbose=, fp=, n=) at lp_test_printf.c:135 #4 0x100150e0 in main (argc=1, argv=) at lp_test_main.c:401 Some single-step debug near the point of SIGSEGV suggests that we are reading a bad pointer value off of $r3 and hit the segv on the btctr. Breakpoint 1, test_printf (gallivm=0x10a11e80, testcase=, fp=, verbose=) at lp_test_printf.c:112 112test_printf_func(0); 0x1001df20 :e9 43 00 00 ld r10,0(r3) => 0x1001df24 :f8 41 00 28 std r2,40(r1) (gdb) info reg r3 r3 0xfffb7f6001017590977429520 (gdb) info reg r10 r100x7c0802a6f8010010 8937396376665391120 0x1001df28 :7c 69 1b 78 mr r9,r3 0x1001df2c :38 60 00 00 li r3,0 0x1001df30 :7d 49 03 a6 mtctr r10 0x1001df34 :e9 69 00 10 ld r11,16(r9) 0x1001df38 :e8 49 00 08 ld r2,8(r9) => 0x1001df3c :4e 80 04 21 bctrl C code for that chunk should match this; so seems like something went wrong handling the return from LLVMGetPointerToGlobal. (32/64-bit ism?) > code = LLVMGetPointerToGlobal(engine, test); > test_printf_func = (test_printf_t) pointer_to_func(code); > >// LLVMDumpModule(module); > >test_printf_func(0); Thanks, -Will ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] powerpc / gallium/drivers/llvmpipe segfaults running lp_test_* tests
On Tue, 2012-07-03 at 16:07 -0500, Will Schmidt wrote: > (gdb) info reg r3 > r3 0xfffb7f60010 17590977429520 > (gdb) info reg r10 > r100x7c0802a6f8010010 8937396376665391120 BenH points out to me that r10 value looks like code. ppcdis 0x7c0802a6 mflrr0 ppcdis 0xf8010010 std r0,16(r1) So we are getting a pointer to the actual code, rather than a OPD (function descriptor). I'll dig into this more... Thanks, -Will ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] powerpc / gallium/drivers/llvmpipe segfaults running lp_test_* tests
On Wed, 2012-07-04 at 05:33 -0700, Jose Fonseca wrote: > - Original Message - > > On Tue, 2012-07-03 at 16:07 -0500, Will Schmidt wrote: > > > (gdb) info reg r3 > > > r3 0xfffb7f60010 17590977429520 > > > (gdb) info reg r10 > > > r100x7c0802a6f8010010 8937396376665391120 > > > > BenH points out to me that r10 value looks like code. > > ppcdis 0x7c0802a6 > > mflrr0 > > > > ppcdis 0xf8010010 > > std r0,16(r1) > > > > So we are getting a pointer to the actual code, rather than a OPD > > (function descriptor). > > > > I'll dig into this more... > > > > Thanks, > > -Will > > I'm not familair with PowerPc architecture. > > Does llvm/examples/HowToUseJIT/HowToUseJIT.cpp work well there? > > If so then you can take a look at lib/ExecutionEngine/JIT/JIT.cpp 's > JIT::runFunction method, and compare what's happening differently. > Thanks for the pointer. It took me a bit to get the example built, but in the end, the behavior appears to be the same. Single-stepping in GDB shows the steps leading up to the SIGSEGV are the same. The value moved into the CTR that we branch to is code rather than OPD. > g++ `llvm-config --ldflags` -o HowToUseJIT HowToUseJIT.o `llvm-config --libs` [willschm@fuzzy Release]$ ./HowToUseJIT We just constructed this LLVM module: ; ModuleID = 'test' Running foo: Segmentation fault [willschm@fuzzy Release]$ gdb ./HowToUseJIT Breakpoint 2, 0x100313c0 in ._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE () => 0x100313c0 <._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE+4032>: e9 3e 00 00 ld r9,0(r30) (gdb) stepi 0x100313c4 in ._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE () => 0x100313c4 <._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE+4036>: f8 41 00 28 std r2,40(r1) (gdb) 0x100313c8 in ._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE () => 0x100313c8 <._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE+4040>: 7d 29 03 a6 mtctr r9 (gdb) 0x100313cc in ._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE () => 0x100313cc <._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE+4044>: e9 7e 00 10 ld r11,16(r30) (gdb) 0x100313d0 in ._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE () => 0x100313d0 <._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE+4048>: e8 5e 00 08 ld r2,8(r30) (gdb) 0x100313d4 in ._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE () => 0x100313d4 <._ZN4llvm3JIT11runFunctionEPNS_8FunctionERKSt6vectorINS_12GenericValueESaIS4_EE+4052>: 4e 80 04 21 bctrl (gdb) 0x7c0802a6f8010010 in ?? () => 0x7c0802a6f8010010: Cannot access memory at address 0x7c0802a6f8010010 Thanks, -Will ___ 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
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
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
[Mesa-dev] [RFC] use mcjit for ppc_64 architecture
Hi, RFC and consideration.. Specify MCJit for ppc64. - Per commentary and direction in the llvm community, support for ppc64 is going into MCJIT rather than the old JIT. There is no existing support in prior llvm versions, so no need to specify LLVM version numbers. Signed-off-by: Will Schmidt --- lp_bld_init.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c b/src/gallium/auxiliary/gallivm/lp_bld_init.c index ffbe3ea..e3b498c 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c @@ -49,7 +49,10 @@ * - MC-JIT supports limited OSes (MacOSX and Linux) * - standard JIT in LLVM 3.1, with backports */ -#if HAVE_LLVM >= 0x0302 || (HAVE_LLVM == 0x0301 && defined(HAVE_JIT_AVX_SUPPORT)) +#if defined(PIPE_ARCH_PPC_64) +# define USE_MCJIT 1 +# define HAVE_AVX 0 +#elif HAVE_LLVM >= 0x0302 || (HAVE_LLVM == 0x0301 && defined(HAVE_JIT_AVX_SUPPORT)) # define USE_MCJIT 0 # define HAVE_AVX 1 #elif HAVE_LLVM == 0x0301 && (defined(PIPE_OS_LINUX) || defined(PIPE_OS_APPLE)) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] use mcjit for ppc_64 architecture
On Fri, 2012-10-05 at 01:48 +0200, Roland Scheidegger wrote: > Out of curiousity is mcjit for ppc64 somewhat working already? Hi Roland, Patches for ppc64 support for mcjit have been going into the llvm tree, so certainly working better now than before. (Better than the existing JIT in any case). > But otherwise looks good to me. Thanks! I don't have commit access. Should I repost without the [RFC], or can you / someone commit this change as-is ? Thanks, -Will > > Roland > > > Am 04.10.2012 23:25, schrieb Will Schmidt: > > Hi, > > RFC and consideration.. Specify MCJit for ppc64. > > > > - Per commentary and direction in the llvm community, support for ppc64 > > is going into MCJIT rather than the old JIT. There is no existing > > support in prior llvm versions, so no need to specify LLVM version > > numbers. > > > > Signed-off-by: Will Schmidt > > --- > > lp_bld_init.c |5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c > > b/src/gallium/auxiliary/gallivm/lp_bld_init.c > > index ffbe3ea..e3b498c 100644 > > --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c > > +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c > > @@ -49,7 +49,10 @@ > > * - MC-JIT supports limited OSes (MacOSX and Linux) > > * - standard JIT in LLVM 3.1, with backports > > */ > > -#if HAVE_LLVM >= 0x0302 || (HAVE_LLVM == 0x0301 && > > defined(HAVE_JIT_AVX_SUPPORT)) > > +#if defined(PIPE_ARCH_PPC_64) > > +# define USE_MCJIT 1 > > +# define HAVE_AVX 0 > > +#elif HAVE_LLVM >= 0x0302 || (HAVE_LLVM == 0x0301 && > > defined(HAVE_JIT_AVX_SUPPORT)) > > # define USE_MCJIT 0 > > # define HAVE_AVX 1 > > #elif HAVE_LLVM == 0x0301 && (defined(PIPE_OS_LINUX) || > > defined(PIPE_OS_APPLE)) > > > > > > ___ > > 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 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
