Skip to main content
gamedev.net
🔒 Locked

Optimizations status

Started by Jeff LaMarche 7 replies 450+ views
Original Post
Jeff LaMarche
Jeff LaMarche
When I first began learning 3D graphics programming, there were a number of optimizations that were fairly common in games and other applications where frame rate and speed were more important than precision. With the increases we''ve seen over the past few years in both processor speeds and in hardware acceleration via graphics cards, have some of these optimizations been rendered (no pun intended) obsolete? The ones I''m most interested in hearing peoples'' experiences with: 1) Doing floating point calculations using fixed point integers - for example, using a long to represent 16 bits on each side of the decimal. All the tutorials and code I see online for OpenGL uses GLfloats for all operations. Has hardware acceleration of OpenGL rendered this practice mostly obsolete, or can you still get significant speed gains without unacceptable precision loss? 2) Lookup tables. It seems like a few years ago, every 3D engine generated a sine and cosine lookup table, and sometimes a tangent lookup table. With projects, tutorials, and source code I''m finding online for OGL, I am not seeing much (any!) use of lookup tables. Obviously there is always, regardless of the state of the art, a point of diminishing returns. There is always some level of precision at which calculating the sine or cosine on the fly becomes more efficient than the lookup table.. have we reached the point where that is usually true for the level of precision needed in modern games, or is this considered a more obscure topic not appropriate to the level of a tutorial. I''d also be interested in hearing peoples'' experiences with using routines such as glRotate as opposed to doing the transformations in your own code. It seems like the OGL translate and rotate (eg) functions would benefit from hardware acceleration when available, so rolling your own transformation code would be of little use, but I''m wondering if anyone has done any comparison to see if this is true.
mhkrause
mhkrause
1)Modern processors are quick enough at floating point, you (generally) don''t have to worry about it. Worry about other areas instead, such as trying to multiply by reciprocal, instead of dividing, caching results of calculations, etc. They''ll probably be bigger wins.

2)LUT''s are still useful, essentially, you''re just caching calculations ahead of time. Most tutorials probably don''t use them just to keep things simple. Calculating sine/cosine, square roots, etc., is still very expensive.

I can''t comment from the OpenGL perspective, but the stories I''ve heard of people writing their own TnL for D3D was that after months of work, they gained 10% speed-up for their application. This is all assuming a traditional Foley & Van Damme pipeline. For D3D, the TnL code is written by teams at Intel and AMD, who presumably know how to optimize code for their chips. For OpenGL, TnL is implemented by the vendor, so performance will probably vary. Nvidia in particular seems to write a very high quality ICD, with good TnL performance. And of course, most OpenGL drivers are optimized for Quake III, which uses GL for TnL, so it''s to their advantage to optimize it.
alistair b
alistair b
i''ve found that lookup tables can speed up sin/cos/sqrt type calculations quite a lot... as for the glRotate & glTranslate, if you know the order, then doing the matrix multiplication maths yourself then making a single glMultMatrix call can be quicker

alistair
alistair b
alistair b
you do the matrix multiplication algebra yourself to save repeated calculations, then you get the program to only work out the bits that change - there''s no point getting it to multiply two 16x16 matrices together if you can know beforehand that half the values will be zero

- i cannot comment on anyone''s code but my own, but it did make mine faster

alistair
Staffan
Staffan
"The Pentium performs trigonometric functions so fast there''s no sense in consuming memory to get a large enough table. For example, when using big hierarchical objects, we''d need enormous trigonometric tables to get a good enough result This is due to cumulativity and the possibly huge size of the object."

http://www.foxfiber.net/3dica/3dica.htm, chapter 2.3

"This album was written, recorded and edited at Gröndal, Stockholm in the year of 2000. At this point in time money still ruled the world. Capitalistic thoughts were wide spread. From the sky filled with the fumes of a billionarie''s cigar to the deepest abyss drenched in nuclear waste. A rich kid was a happy kid, oh..dirty, filthy times. Let this be a reminder."
- Fireside, taken from back of the Elite album

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.