Timothy Miller wrote:
<SNIP>
Don't get too caught up in what people tend to mean by CISC and RISC.
The MIPS processor has a SQRT instruction that takes over 100 cycles
and incurrs all sorts of structural hazzards (resource contention)
against other FP operations. Our goal should be to design a
straight-forward, simplified instruction set. That means if we want
to sparsely populate an instruction word, we should do it. And we
should do all sorts of clever things that implement multiple types of
operations with the same instruction (like how some MIPS opcodes are
really aliases for others where R0 is implicit). Sorry. I have MIPS
on the brain.
Floating point isn't really RISC, you have a RISC processor with a FPU
since the FPU couldn't execute stuff in one clock. And, then methods
were developed to accelerate the FPU so that it could execute in one clock.
What we really need to decide is how to handle operations (such as
matrix math) which require a series of steps for the ALU to complete.
We can use CISC like operations where the series of operations is in
microcode. Or we can have a RISC like control of the ALU where we have
SIMD that can operate on up to 4 32 bit floats in parallel and issue a
series of instructions to do what one CISC like operation would do.
But, you can combine these like the transputer and have the OP
instruction which calls a macrocode subroutine to do these things.
I can't see having more than one ALU per shader since it should have 4
32 bit float hardware multipliers. Since the standard shader operation
is multiplying three 4x4 matrices, it is the hardware multipliers that
is going to boost throughput.
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
