[Open-graphics] CPU on graphics card]

[Nicolas Boulay]

2007/4/18, Hugh Fisher <hugh.fisher at anu.edu.au>:
> Attila Kinali wrote:
> >
> > Although you can see shaders as a form of CPU,
> > they are a very specialized form of CPU. And they
> > have to be specialized to achieve the performance needed.
> > Thus i would not talk of shaders as CPUs.
>
> They have an instruction set with 4 x 32 bit floating point
> registers like AltiVec/SSE, which can also be used for
> scalar operations like the conventional regs on a CPU. They
> have add, sub, mul, div, like a conventional ALU, plus some
> more specialised dot/cross product type operations which
> are like those in AltiVec and SSE. (There is no requirement
> in OpenGL shading languages that a matrix multiply be
> executed as a single operation: all the cards I know of
> implement it as a series of instructions.)
>

Don't forget also than GPU have very special adressing mode. They have
means to access 2D pattern in a texture by using x,y coordinate + a
texture ID. It's save you many "RISCY" calculation involve in
something looking as (*texture[n])[x][y].

In a NVIDIA paper, they describe more than 20 data type. pixel in
8-8-8-8 format, in 6-6-6, in yuv format 8-4-4, in packet format (4
pixels in 32 bits), vertex coorindate, etc... I imagine also easy
access to any sub fields. This complexe access pattern save a lot of
calculation which should be done in normal cpu. They look like they
have a lot of register : half to access the graphical pattern, the
texture buffer, the Z-buffer without using only a memory buses, the
other half register look normal one to avoid any external memory
access for calculus.

shader look like DSP. Everything should be done to fully used the
FMACC unit (most instruction are FMACC or FADD). So everything else
are quite known (access to texture, to vertex) and could be accelerate
in specific unit.

A  good shader core maximise the number of FMACC per gate used (on
real shader code !). If you need more performance, add more core.