[Plib-devel] Re: 3DNow! acceleration

[Sam S. <sa...@sp...>]

----- Original Message -----
From: Steve Baker <sjb...@ai...>
To: <pli...@li...>
Sent: Saturday, April 01, 2000 6:07 AM
Subject: Re: [Plib-devel] Collision detection in PLIB/SSG


> Sam Stickland wrote:

>
> > I also have code (from AMD's website) from 3DNow! acceleration (windows
only
> > unfortunately), that would be very easy to plug into SG (and I do mean
very
> > easy - it's just a bunch of function calls).  I'll add this next week
some
> > time.
>
> Hmmm - be careful.
>
> Taking a single 3D transform (say) and turning that into a 3DNow!
instruction
> sequence provides a disappointingly tiny speedup.
>
> The reason for that disappointing performance is that turning the
> 3DNow! engine on and off is horribly slow.
>
> The way to get blazing speed out of 3DNow! is to queue up a large buffer
> of vertices to be transformed - and to do them all in a batch without
> having to turn it on and off again.  Mesa eventually needed significant
> restructuring to make 3DNow! actually worthwhile.
>
> However, something like SSG doesn't ever need to do large numbers of
> consecutive transforms - most of what it's doing (that consumes
> significant CPU time) is culling the database to the field of view
> (or to the collision test vector/sphere).  By it's very nature,
> this isn't something that is readily batch-able.

Surely to do the field of view cull you have to transform every vertex in
the scene by the modelview matrix?  Isn't this the sort of thing that 3DNow!
could really speed up? (You can just leave the modelview matrix in the
required registers and push through all the vertices really quick).

Or perhaps this kind of approach isn't suited to PLIB?

> So, I don't think 3DNow is actually worth the maintenance hassle.
> Bear in mind that it would have to compile under both Windoze and
> Linux (and perhaps BSD UNIX) - that's no easy matter since the
> Linux and Windoze assemblers accept different input syntax - and
> even withing Windoze, some of the older MSVC versions don't know
> about the 3DNow instruction mnemonics (ditto with Linux/gcc I
> suspect).   Then you need runtime code to detect whether the code
> is *running* on a 3DNow-capable machine.  That code has to work on
> all 8086-family CPU's - but not on Alpha's and MIP's and such.

AMD provide code to detect whether 3DNow! acceleration is supported (this
works on all x86 processors), as well as code to detect MMX and SSE
instructions.  Turning it off on non x86 processors could be easily done as
a compile time option, although I'm sure there are ways of detecting this at
run-time (but that's probably a bit of a kludge).

Sam