n3f v3f timing

[Kurt Akeley]

In article <15146 at darkstar.ucsc.edu>, root at fuzzy (Dr. Michael M. Cohen) writes:
|> Query on the temporal characteristics of the n3f v3f calls:
|> Do these return to the main program only after transfer is
|> complete or are they asynchronous in the sense that they just start
|> transfer and next call will wait if the hardware is not ready?
|> My situation is that for about 1k polygons, it's taking about
|> 10 msec to compute the normals followed by about 10 msec to
|> send the polygons. If the vertex sending calls are asynchronous
|> perhaps I can interleave the normal calculations with the
|> n3f v3f calls to do the job in less than the 10+10 msec it's now
|> taking... If anyone has assembly language routines for computing
|> polygon and vertex normals more efficiently than what the c
|> compiler can produce, I'd be real interested in taking a look!

The n3f/v3f calls block only until the vector data have been copied from
your data space, not until the drawing commands have actually been
completed.  Typically the data are copied to the head of a several hundred
word fifo, which tail is connected to the graphics hardware.

You will almost certainly win by mixing your normal calculations with your
polygon traversal.  The fifo is long enough to hold several complete
polygons.  Optimally coded, using mesh primitives, a triangle can be sent
to the hardware in well under 2 microseconds.  Since your graphics are
currently running at about 10 microseconds per polygon, there are 8
microseconds left for computation.

In your previous posting you asked whether meshed primitives would help
your performance, and I sent you a direct reply saying no, because your
performance was obviously fill limited.  I assumed (oops) that you
computed normals only once, as is the case for a static model.  If they
msut be recomputed every frame, this work is best intermixed with the
drawing, in which case meshing may help.

-- Kurt