Comment by DesiLurker
6 years ago
what I'd like is a programmable vector math unit with adjustable vector length so I can do massive compute operations without having to pay memory access latency cost. for instance, it would be awesome if CPU can just instruct to do alpha blend 2 frames command to the memory and avoid the whole fetch decode execute loop altogether.
On top of this it would be really awesome if this attached 'ram compute block' was re-programmable like fpgas or a simpler higher level construct. then we could essentially do all the 'parallel & dumb' computations in ram itself so CPU would mostly be for control and branch code.
With 5nm coming soon, I think this is inevitable. It's now possible to put 127M transistors in a single square millimetre, but despite billions of transistors in a CPU, total performance is not hundreds of thousands of times greater than primitive CPUs from decades ago.
It would cost next to nothing in terms of chip area to have a simple "controller" CPU in each DRAM chip that can issue vector instructions without needing to have its hand held.
The problem is the instruction set: where do you stop? Do you just have simple logic operations, or a full set of floating point operations? Do you have flow control? Stacks? Etc...
Code would either have to be written in the "full featured" language as well as a cut-down language similar to CUDA, or the embedded little chips would have to be full CPUs.
The other issue is cache coherence. It's possible to have designs where either the little DRAM CPUs participate or they don't. Both have big advantages and big disadvantages, and neither is easy.
I suspect that this is going to start turning up in GPUs before CPUs, or possibly for HPC applications before general purpose computers.
Since designing and perfecting new, highly parallel programming methods is hard, I can imagine stretching current approaches.
Spread ALUs and simple control units across RAM cells, there's little needed because the RAM is its own registers. Some distant big control unit will send out instructions to the processing units, and orchestrate I/O. A bit like GPU but with a different set of constraints. Likely it could be made compatible with OpenCL or CUDA.
cache coherence is a valid concern but I anticipate a clever snooping hardware could invalidate the 'touched' regions, btw this is already done for numa architecture based systems for a while.
regarding vector instruction explosion, this why I left a remark around programmable fabric (which does have to be super fast reconfigure). this way you could morph a bunch of logic blocks into whichever flavor you want. btw this is also not a first either, companies like Stretch & Mathstar have tried to do similar re-programmable fabrics & more recently altera had done re-programmable fabric using parallel/gpgpu languages like OpenCL. one good thing with programmable fabric in this context is that there is not an immense pressure to fit logic in a cycle budget because you can always claim a certain vector instruction takes X cycles to complete without effecting simpler operations taking Y (<< X) cycles.
cache coherency issues notwithstanding, you are right about it turning up in GPUs first, simply because as the target resolution scales past 4k & 8k, VR etc it would be imperative to do a lot of similar parallel operations on huge chunks of memories and memio b/w would be the biggest bottleneck there. this could mostly alleviate that.
what I am unclear about is how does putting programmable fabrics like this impacts DRAM yields?
Slightly OT, but have you seen https://fuse.wikichip.org/news/3256/centaur-new-x86-server-p...
Cha, Cha, Cha!