[ODE] Ideas for threading ODE...
jsinecky at tiscali.cz
Sat Aug 20 09:31:44 MST 2005
In fact in our ODE-based game I tried to put physics in a separate thread
expecting we could gain some performance even on single-core processors
simply because during rendering it's GPU who works more, isn't it? Or at
least there is high possibility that CPU gets idle when GPU task queue gets
full or while waiting to finish rendering the frame and swap buffers. But we
didn't notice any gain at all :-(
Has some else tried this? Is my assumption about CPU possible idle during
We use DirectX for rendering, but in some other little OpenGL based project
some time ago, I put some application stage code (precomputing for next
frame) in between last rendering command and swapBuffers call and got really
cool fps increase. (This was all on just one thread though)
> -----Original Message-----
> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf
> Of Jon Watte (ODE)
> Sent: Friday, August 19, 2005 8:21 PM
> To: Tyler Streeter
> Cc: ode
> Subject: Re: [ODE] Ideas for threading ODE...
> > Using OpenMP (http://www.openmp.org) would make it easy to add support
> > for multiple threads. OpenMP is great for data parallelism, which I
> I think OpenMP is not the right solution for PC architectures and game
> You could multi-thread ODE by putting the entire stepper in a different
> thread, and have the application do other useful work in the meanwhile.
> You can provide double-buffering or snapshotting of body state
> (position/orientation) to make it easy to do rendering in the
> non-physics thread.
> The collision callbacks have to be carefully structured to not interlock
> with the main world update and AI, but that's a reasonable restriction.
> Any finer-grain threading than that is unlikely to lead to performance
> gains for PC games. In fact, may lead to lower performance.
> / h+
> ODE mailing list
> ODE at q12.org
More information about the ODE