> From an architecture standpoint why not go for 5 execution unit in one
> bloc.  On those 5 unit one is dedicated for memory management load store
> register and data mouvement, the other make a single execution unit for
> vector operation or 4 distinct unit for scalar operation. Each unit
> could do only a subset of the scalar operation, they don't all need to
> be able to do the same one, also it will help reduce the overal size of
> each unique execution bloc.
>

That's basicaly a LIW or VLIW instruction set. If you put many operation
in parrallel, you need also a lot of register read/write per cycle. Read
and write in a register bank is quite a slow operation (LEON 3 processor,
a 7 stage pipeline cpu, use a complete cycle to do it). If you add more
register port you slow done the acces time of the bank.

So the speed-up must be higher than this loose. But to acheive high
throughput you need to fill well the instruction slot. That's a hard stuff
(see the Intel problem with itanium compiler)

In my previous proposal, i use LIW trick for managing the Program Counter
and use predicat which read an other register bank. You could also
multiply register bank to avoid slowdown but then you will have problem
for exchanging the data. This could add few more MOV instruction.

If you want more speed on a task for a given silicon technology, you could
use VLIW technique, SIMD one, scoreboard, out of order, etc... All of this
is used in todays big cpu.

But you could also be multi-cpu, multi-core. In a tradionnal computing,
the killer is communication between core. That's why a 1000 cpu computer
could be slower than a 6 vector cpu (from Cray or Nec). But from a raw
power point, the 1000 cpu is faster. But in real world exemple, it is
slower.

In shader, there is no communication. So, multicore is from my point of
view the better way to do it.

Nicolas Boulay


_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to