[ODE] Ideas for threading ODE...

[Jon Watte (ODE)]

> 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.

Cheers,

			/ h+