Timothy Miller wrote:
<SNIP>
quoted text
> 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
Open-graphics@duskglow.com
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)