🚀 go-pugleaf

Andy Glew 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.
> 
> Probably less than 5 years, but I want to have a bit of slack.

That's easy: It _will_ happen, simply because it is a static target for
the cpu guys (i.e. that's you, Andy) to aim at. :-)

Initial implementations will be like what we have today, i.e. partial
operations implemented as 4-wide operations, join a few of them to get
the final result.

This is similar to the divide/multiply step opcodes on early risc
machines.

As soon as enough gates were available, we got DIV/MUL instead.

Similar to the special requirements for some of the DIV/MUL
implementations (special and/or implied register usage), the geometry
accelerator might require setting up the matrix in a special way.

It seems reasonable to require that it should be loaded into either a
single 16-wide vector register, or into a consequtive list of narrower
registers, so that just the start of the matrix has to be specified in
the instruction:

On the PentiumV (or VI, who knows how long it will last?) it will use
the two-operand MATMUL opcode, with the transformed vector ending up in
the input register:

  MATMUL vecreg, matreg

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"