similar to: [LLVMdev] Help adding the Bullet physics sdk benchmark to the LLVM test suite?

On Tuesday 05 January 2010 14:53, Erwin Coumans wrote: > How do other benchmarks deal with unstable algorithms or differences in > floating point results? > > >> haven't been following this thread, but this sounds like a typical > >> unstable algorithm problem. Are you always operating that close to > >> the tolerance level of the algorithm or are there

Hello, Erwin > I suggest working on a better benchmark that tests independent parts of the > pipeline, > so we don't accumulate results (several frames) but we test a single > algorithm at a time, > with known input and expected output. This avoid unstability and we can > measure the error of the output. > Anton, are you interested in working together on such improved

The linux builds are not using SSE right now, but the vector data is 16-byte aligned on all platforms. So if you port this SSE code to another platform (Linux, Altivec, NEON), you could contribute it back to Bullet? The most interesting SSE part is the innerloop of the constraint solver: http://tinyurl.com/ydoapct Some developers replaced some linear algebra functions (in Bullet/LinearMath) with

Hi Anton, and happy new year all, >>One questions though: is it possible to "verify" the results of all >>the computations somehow? Good point, and there is no automated way currently, but we can work on that. Note that simulation suffers from the 'butterfly effect', so the smallest change anywhere, (cpu, compiler etc) diverges into totally different results after a

On Dec 15, 2009, at 5:15 PM, Erwin Coumans wrote: > The linux builds are not using SSE right now, but the vector data is > 16-byte aligned on all platforms. > So if you port this SSE code to another platform (Linux, Altivec, > NEON), you could contribute it back to Bullet? > The most interesting SSE part is the innerloop of the constraint > solver: http://tinyurl.com/ydoapct

Hello, Erwin > So if you port this SSE code to another platform (Linux, Altivec, > NEON), you could contribute it back to Bullet? I believe this should work as-is on linux. Am I missing something? > optimizations, but haven't contributed this back. > This NEON/VFP, part of the an open source iPhone project, could be a > starting point for this: > http://tinyurl.com/y9gv3e8

Hi, We are developing the open source Bullet physics engine, used by game and movie studios, and compiler performance tuning is important to us. See http://bullet.googlecode.com The physics engine includes collision detection, rigid body dynamics and soft body dynamics. I've been following the LLVM project for a while, and it seems the Clang C++ compiler is mature enough to compile our

Hello, Erwin > The physics engine includes collision detection, rigid body dynamics and > soft body dynamics. This sounds really promising addition to LLVM testsuite! > to compile our source tree and benchmarks. Bullet 2.75 uses a lot of > SIMD-friendly vector operations, Which archs are currently supported for SIMD operations? > The SDK is under Bullet/src and the benchmarks

Hello, Erwin > If you are interested, I think it is best to start with Bullet 2.75. > If it turns out that LLVM requires some modifications (due to current C++ > limitations), > we can modify Bullet and go for an uncoming release such as Bullet 2.76 > (planned around January 2010). I added bullet to LLVM testsuite. Basically I had to flatten source directories since this is a

On Jan 5, 2010, at 1:38 PM, David Greene wrote: > I don't think there's a flag that says "don't do anything risky, > ever." "Don't do anything risky with floating-point" is the default mode. If you're aware of any unsafe floating-point optimizations being done by default, please file a bug. > For example, a gfortran-fronted LLVM should have a way

Hello, Erwin > Although most of this is plain portable C++ perhaps LLVM can auto-vectorize > some of this? Well, I doubt so, unfortunately - LLVM does not have any autopar these days > There is a little bit of hand optimized x86 SSE code. This is only enabled > on 32bit Windows and Mac OSX Intel builds. Ok. What's about Linux builds? Are there any other implementations e.g.

We haven't determined what 'failing' means or what the 'correct' behaviour is. Imagine a ball at the top of a rounded hill. If the ball is not exactly at the top but a tiny amount on the left it will roll left, but a tiny amount on the right it will roll right. The difference in initial position can be negligible but the final result is miles away. Is there a irc channel or

Hi Anton, Thanks a lot for offering help. Bullet uses basic linear algebra with 4-way vectors, quaternion and matrices. Although most of this is plain portable C++ perhaps LLVM can auto-vectorize some of this? There is a little bit of hand optimized x86 SSE code. This is only enabled on 32bit Windows and Mac OSX Intel builds. >> Should I just use the 2.75 release? If you are interested,

On Tuesday 05 January 2010 15:57, Dan Gohman wrote: > On Jan 5, 2010, at 1:38 PM, David Greene wrote: > > I don't think there's a flag that says "don't do anything risky, > > ever." > > "Don't do anything risky with floating-point" is the default mode. If > you're aware of any unsafe floating-point optimizations being done by >

Hello, Everyone > Sounds like a very interesting SSE test. I'm working on it. Hopefully it will be added today or tomorrow to LLVM testsuite. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi. I was wondering if anyone has compiled Bullet Physics for WindRiver's vxWorks (or know of anyone who may have done so). Any insight / info / help would be very much appreciated. Thanks! -Ryan (aka keppy) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100120/53f5b439/attachment.html>

Eliminate undefined references to powf, sqrtf and friends. Index: MultiSource/Benchmarks/Bullet/Makefile =================================================================== --- MultiSource/Benchmarks/Bullet/Makefile (revision 92512) +++ MultiSource/Benchmarks/Bullet/Makefile (working copy) @@ -1,7 +1,7 @@ LEVEL = ../../../ PROG = bullet CPPFLAGS += -I$(PROJ_SRC_DIR)/include -DNO_TIME -LDFLAGS

Index: MultiSource/Benchmarks/Bullet/Makefile =================================================================== --- MultiSource/Benchmarks/Bullet/Makefile (revision 92478) +++ MultiSource/Benchmarks/Bullet/Makefile (working copy) @@ -1,6 +1,6 @@ LEVEL = ../../../ PROG = bullet -CPPFLAGS += -Iinclude -DNO_TIME +CPPFLAGS += -I$(PROJ_SRC_DIR)/include -DNO_TIME LDFLAGS = -lstdc++ include

I checked by Alpha this morning after it's been running fine for a while and saw this on the terminal (hand transposed): Jun 14 08:54:55 erwin getty[2087] : getty : retreiving gettytab entry 'default': Device not configured Jun 14 08:54:55 erwin getty[2087] : getty : retreiving gettytab entry 'Pc': Device not configured Jun 14 08:54:55 erwin getty[2087] : getty : retreiving

Hi all, Having a bit of a problem with portupgrade on a -STABLE machine: [root@erwin]/root: portupgrade -aRn ---> Session started at: Tue, 27 May 2003 22:54:00 +1000 closed stream ---> Session ended at: Tue, 27 May 2003 22:54:01 +1000 (consumed 00:00:01) [root@erwin]/root: pkgdb -F does the same thing. Any clues? cheers, Rob [root@erwin]/root: uname -a FreeBSD erwin.number6