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

Remove colour attributes from body and strip most of the font tags out

Browse source
This commit is contained in:
James Gregory 2013-12-30 13:57:02 +11:00
commit c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
Download patch file Download diff file Expand all files Collapse all files

10
63-04.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=63//-->
<!--PAGES=1173-1175//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -83,14 +83,14 @@
; ends on cycle 33
</PRE>
<!-- END CODE //-->
<H3><A NAME="Heading10"></A><FONT COLOR="#000077">Projection</FONT></H3>
<H3><A NAME="Heading10"></A>Projection</H3>
<P>The final optimization we&rsquo;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&rsquo;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&rsquo;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.
</P>
<P>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&rsquo;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&rsquo;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&rsquo;d expect from the precise clip point, or the need for using larger epsilons in comparisons for point-on-plane tests.</P>
<H3><A NAME="Heading11"></A><FONT COLOR="#000077">Rounding Control</FONT></H3>
<H3><A NAME="Heading11"></A>Rounding Control</H3>
<P>Another useful area that I can note only in passing here is that of leaving the FPU in a particular rounding mode while performing bulk operations of some sort. For example, conversion to int via the FIST instruction requires that the FPU be in chop mode. Unfortunately, the FLDCW instruction must be used to get the FPU into and out of chop mode, and each FLDCW takes 7 cycles, meaning that compilers often take at least 14 cycles for each float-&gt;int conversion. In assembly, you can just set the rounding state (or, likewise, the precision, for faster FDIVs) once at the start of the loop, and save all those FLDCW cycles each time through the loop. This is even more true for <B>ceil()</B>, which many compilers implement as horrendously inefficient subroutines, even though there are rounding modes for both <B>ceil()</B> and <B>floor()</B>. Again, though, be aware that results of FP calculations will be subtly different from compiler default behavior while chop, ceil, or floor mode is in effect.</P>
<P>A final note: There are some speed-ups to be had by manipulating FP variables with integer instructions. Check out Chris Hecker&rsquo;s column in the February/March 1996 issue of <I>Game Developer</I> for details.</P>
<H3><A NAME="Heading12"></A><FONT COLOR="#000077">A Farewell to 3-D Fixed-Point</FONT></H3>
<H3><A NAME="Heading12"></A>A Farewell to 3-D Fixed-Point</H3>
<P>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&rsquo;ve mentioned. Nonetheless, I&rsquo;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&rsquo;t expect to be doing a whole lot of fixed-point 3-D math from here on out.
</P>
<P>And I won&rsquo;t miss it a bit.</P><P><BR></P>
@ -106,7 +106,7 @@
<hr width="90%" size="1" noshade>
<div align="center">
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book &copy; 2001 Michael Abrash</font>
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div>
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->