Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

26
63-04.md
View file

@ -12,11 +12,11 @@ if done one after the other using the faster dot-product code of Listing
When fully interleaved, however, only a single cycle is lost (again to
the extra cycle of FST latency), and the cycle count drops to 34, as
shown in Listing 63.6. This means that on a 100 MHz Pentium, it’s
shown in Listing 63.6. This means that on a 100 MHz Pentium, it's
theoretically possible to do nearly 3,000,000 transforms per second,
although that’s a purely hypothetical number, due to cache effects and
although that's a purely hypothetical number, due to cache effects and
set-up costs. Still, more than 1,000,000 transforms per second is
certainly feasible; at a frame rate of 30 Hz, that’s an impressive
certainly feasible; at a frame rate of 30 Hz, that's an impressive
30,000 transforms per frame.
**Listing 63.6 L63-6.ASM**
@ -64,28 +64,28 @@ certainly feasible; at a frame rate of 30 Hz, that’s an impressive
### Projection {#Heading10}
The final optimization we’ll look at is projection to screenspace.
The final optimization we'll look at is projection to screenspace.
Projection itself is basically nothing more than a divide (to get 1/z),
followed by two multiplies (to get x/z and y/z), so there wouldn’t seem
followed by two multiplies (to get x/z and y/z), so there wouldn't seem
to be much in the way of FP optimization possibilities there. However,
remember that although FDIV has a latency of up to 39 cycles, it can
overlap with integer instructions for all but one of those cycles. That
means that if we can find enough independent integer work to do before
we need the 1/z result, we can effectively reduce the cost of the FDIV
to one cycle. Projection by itself doesn’t offer much with which to
to one cycle. Projection by itself doesn't offer much with which to
overlap, but other work such as clamping, window-relative adjustments,
or 2-D clipping could be interleaved with the FDIV for the next point.
Another dramatic speed-up is possible by setting the precision of the
FPU down to single precision via FLDCW, thereby cutting the time FDIV
takes to a mere 19 cycles. I don’t have the space to discuss reduced
takes to a mere 19 cycles. I don't have the space to discuss reduced
precision in detail in this book, but be aware that along with
potentially greater performance, it carries certain risks, as well. The
reduced precision, which affects FADD, FSUB, FMUL, FDIV, and FSQRT, can
cause subtle differences from the results you’d get using compiler
cause subtle differences from the results you'd get using compiler
defaults. If you use reduced precision, you should be on the alert for
precision-related problems, such as clipped values that vary more than
you’d expect from the precise clip point, or the need for using larger
you'd expect from the precise clip point, or the need for using larger
epsilons in comparisons for point-on-plane tests.
### Rounding Control {#Heading11}
@ -107,20 +107,20 @@ different from compiler default behavior while chop, ceil, or floor mode
is in effect.
A final note: There are some speed-ups to be had by manipulating FP
variables with integer instructions. Check out Chris Hecker’s column in
variables with integer instructions. Check out Chris Hecker's column in
the February/March 1996 issue of *Game Developer* for details.
### A Farewell to 3-D Fixed-Point {#Heading12}
As with most optimizations, there are both benefits and hazards to
floating-point acceleration, especially pedal-to-the-metal optimizations
such as the last few I’ve mentioned. Nonetheless, I’ve found
such as the last few I've mentioned. Nonetheless, I've found
floating-point to be generally both more robust and easier to use than
fixed-point even with those maximum optimizations. Now that
floating-point is fast enough for real time, I don’t expect to be doing
floating-point is fast enough for real time, I don't expect to be doing
a whole lot of fixed-point 3-D math from here on out.
And I won’t miss it a bit.
And I won't miss it a bit.
------------------------ --------------------------------- --------------------
[Previous](63-03.html) [Table of Contents](index.html) [Next](64-01.html)