Re:Open Source GPGPU
by cfallin on Sunday June 01, 2014 @08:20PM
(#7831252)
Yes, there would be huge practicality issues with a "wafer-scale" FPGA -- aside from propagation delays, as you note, the chip would have horrible manufacturing yield, because any defect anywhere on the wafer would produce a defective chip. (In contrast, when a wafer has a bunch of tiny chips, a given defect only takes out one small chip, and you still have the other N-1 to use.) Ultimately this drives up cost to the end-user.
Fab equipment also has limits in how big a single chip can be due to "reticle limits", i.e., the size of a single mask exposure, and a chip has to be a single exposure (per layer).
The CAD software (place+route) might actually be a limiter here too. Even if, in theory, you had an FPGA with enough logic blocks to match a modern GPU's raw gate count (i.e., circuit size), an FPGA is just a sea of identical configurable blocks and parts of the circuit are assigned to the blocks and connected with wires using something like simulated annealing. This is why FPGA place+route takes so long. In contrast, a custom chip can put exactly the right gates and wires at exactly the right places, and especially for something like a GPU or a large cache where there are lots of repeated elements, this human involvement makes things much more tractable. (It's also why e.g. the caches on a modern CPU die look so pretty, like a big grid of farms or something -- an FPGA-synthesized CPU cache would look nothing like that, and take much more space!)
All of that said -- from an academic point of view, this GPGPU core is an impressive piece of work, especially given that it includes an LLVM backend!
Fab equipment also has limits in how big a single chip can be due to "reticle limits", i.e., the size of a single mask exposure, and a chip has to be a single exposure (per layer).
The CAD software (place+route) might actually be a limiter here too. Even if, in theory, you had an FPGA with enough logic blocks to match a modern GPU's raw gate count (i.e., circuit size), an FPGA is just a sea of identical configurable blocks and parts of the circuit are assigned to the blocks and connected with wires using something like simulated annealing. This is why FPGA place+route takes so long. In contrast, a custom chip can put exactly the right gates and wires at exactly the right places, and especially for something like a GPU or a large cache where there are lots of repeated elements, this human involvement makes things much more tractable. (It's also why e.g. the caches on a modern CPU die look so pretty, like a big grid of farms or something -- an FPGA-synthesized CPU cache would look nothing like that, and take much more space!)
All of that said -- from an academic point of view, this GPGPU core is an impressive piece of work, especially given that it includes an LLVM backend!