🚀 go-pugleaf

In article <36DF4F87.FFDEFF0C@cs.wisc.edu>,
Andy Glew  <glew@cs.wisc.edu> wrote:
>> I'd not be amazed if it actually achieved that - what they seem to be
>> claiming is one-tick-throughput matrix-vector multiply, which is
>> probably achievable. Essentially it's a 300MHz geometry accelerator.

>Prediction: within 5 years, a single instruction that performs a 4-vector
>by 4x4-matrix multiply, of 32 bit FP numbers, will be as common as
>vector FP and integer (MMX, KNI, 3DNow) are now.

   Prediction: within 2 years, a lot of that functionality for matrix
multiplies will be sitting on your 3D video board, as off-CPU geometry
processors get more and more common. Even a slightly stripped down
version of the PSX2 CPU on the video board would be a serious
improvement to overall system speeds. If you're doing NURBS and
dynamic tessellation, that's a boatload of polygons generated, and
it's far better to not bog down the system bus with that data-- keep
it on the 3D card where mega-bandwidth is available.

   Profiling by folks of common 3D games (see also one of Brian Hook's
recent .plan updates) show that in a large number of apps, the app is
getting less than *half* of CPU time. The 3D API {OpenGL|D3D} and the
3D card's drivers are the culprits here, and the more work they do
that can be shifted to the 3D card, the better. Intel and AMD are
gonna hate geometry accelerators, as that sinks their marketing plans,
but if the system is overall faster withOUT a new CPU, I won't mind.

Nathan Mates

--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/  
# Network Programmer, Battlezone 2: see http://www.pandemicstudios.com
# NOT speaking for Pandemic Studios or Activision, ONLY myself
# "What are the facts, and to how many decimal places?" -R.A. Heinlein