[ODE] Ideas for threading ODE...
Jon Watte (ODE)
hplus-ode at mindcontrol.org
Mon Aug 22 14:28:17 MST 2005
> Yeah... but I don't think they do this just for benchmarks - it's really the
> philosophy. It helpful to think of the graphics card as a separate computer
> on a 100% reliable network. For best frame-rate, you wouldn't wait for an
> ack from the graphics card before you rendered the next frame... you'd just
> want to keep telling it what to do as fast as you could.
The ack comes from the card in the form of an interrupt. They could just
as easily call SetEvent() from the interrupt handler as they could set
the flag they're spin-waiting on. (ignore the rules for what interrupt
handlers vs DPC can do in the kernel at various interrupt levels for
now; it can be accomplished)
However, they choose to use a spinlock rather than a proper (scheduler)
primitive. The reason for this is all about performance; it has nothing
to do with the asynchronicity of the hardware.
And it's extra sad, because almost all modern games running on modern
graphics cards are CPU limited -- there's tons of fill to spare, but the
command set-up code, vertex and texture management, and other
DirectX/driver layer CPU work, plus the physics of the game, will
conspire to not push the card as fast as it'll go. Of course, in those
cases, the FIFO won't fill up, and there won't be any spinlock stalls.
More information about the ODE