Hacker News Reader

Comment by timlatim | Hacker News Reader

I wonder if we'll ever see FPGAs in consumer CPUs, given AMD's expertise with chiplets and interconnects. Say, for programmable specialized instructions. The relatively recently published patent "Method and apparatus for efficient programmable instructions in computer systems" (https://www.freepatentsonline.com/y2020/0409707.html) seems to point that way.

View on HN

This is an idea that's been around forever and from a hardware perspective it's super easy. The problem is finding applications for this. You need to find something that is so difficult that it requires atleast dozens of instructions (because the FPGA isn't going to be running at the CPU clock speed so it needs to be a decent chunk of work to jsutify), is done often enough to dedicate silicon for (the FPGA can't be dark 99.999% of the time), but not often enough that you can't justify full custom implementation. Then you need to write a set of custom instructions that map to this logic, and build support for using these custom instructions into the compiler - accounting for the fact you don't just need to dispatch data to the fpga, you need to program it each time you change instruction and that takes forever in CPU terms.

It's not impossible, it's just very difficult, impacts every single part of the stack, and is very difficult to justify.

Maybe they're targeting a different arch layer? Is there any mileage in pushing that sort of tech into on-chip routing? As you get more and more cores, obviously interconnect area becomes more of a problem (and bus bandwidth more constrained). Is there much to be gained from a compiler being able to say "This next bit of code wants as much uncontended bandwidth as you can muster between 5 cores and L1"? That way, actually reconfiguring anything would be a bunch of microcode, rather than something the compiler took direct control over.

There's some (perhaps lots) of potential for this for in-memory analytic processing (e.g. in an analytics-focused DBMS).

Also, a specific potential use of FPGAs is for pattern matching on large amounts of text/data: If you do it at all, you're likely to do it often; and it can't be a custom implementation since the circuit depends on the specific pattern.

Correct but at the same time that overstates things, because extremely often the choice between full custom ICs versus FPGA is dictated by the expected volume of product, not just functionality considerations.

It is typically simply cheaper to deploy FPGAs in released products when the volume is small, while it may be cheaper to use full custom when the volume is in the millions to hundreds of millions, in the cases where either solution is functionally workable.

That includes amortizing the non-recurring engineering costs over the total units, which is typically higher for full custom than FPGA -- although sometimes they are actually in the same ballpark.

Aside from that you are correct; people sometimes imagine that most any application can be significantly accelerated with FPGAs, but even in the cases where fine-grained parallelism is present to be accelerated (well-known not to be the case for all application areas), the FPGA solution space is decreased by the solution space where full custom makes engineering and financial sense.

Intel at one point tried an FPGA-in-package with a server CPU. It turns out that you can't downclock/power gate parts of FPGA designs nearly as easily as you can CPU components, so the whole package had thermal regulation issues. You had to run the CPU at a very conservative frequency in order to let the FPGA use power as it needs to.

There are FPGA-SoCs out there that are mostly FPGA, and that seems like the way to go if you want to combine FPGAs and CPUs, otherwise they should probably be on separate power and heat budgets.

Wondering the same; from my 10,000 ft view a cpu-fpga marriage seems like the kind of thing that could transform how performant general purpose computing is done.

The same was said back when AMD started making APUs (CPUs with on-board GPUs) and I was similarly hopeful, but we saw how that went. Most attempts at heterogeneous computing have gone only as far as sticking two previously separate chips in one package - no significant integration or co-operation. Since FPGAs are even more different from CPUs than GPUs are, even more programming effort will be needed to take advantage of them, so unless AMD make some kind of revolutionary framework for programming them, I fear FPGA acceleration will get even lower use than GPUs do (excluding 3D work, of course).

APUs have come a long way since the initial ones. AMDs own are now actually decent in 1080p gaming. I built my wife a gaming pc and didn't buy a dedicated gpu, just an AMD APU and can play CS GO maxed out at decent fps.

I think we can all agree that APUs have come a ways since first coming out. The poster you replied to was more lamenting how the inclusion of a GPU into my CPU didn't create something bigger than the sum of its parts.

What we have is still a CPU and a GPU. Separate. Discrete. The inclusion changed nothing about what kind of software we can write or problems we can solve. Back when APUs were still just a slide in a powerpoint deck, there was a lot of talk about how this could "change everything" because of the radically different type of compute you could do on a GPU.

The closest thing to this is the coin mining craze, but everyone is gravitating towards the fastest hardware for that. And that's not your APU.

Yeah, as the first sibling comment said, I was more talking about the new generation of computing APUs were supposed to bring us, instead we got GPUs that happen to be on the same chip as the CPU. AMD's APUs are definitely awesome, especially the Ryzen+Vega ones, and if they made a Ryzen 7+Vega 10 chip for desktop, I'd buy it immediately, but it's still just a GPU that does standard GPU things - the fact that it's integrated is little more than an implementation detail.

Seems doubtful. I thought that way too in the '90s but what happened was that anything that was a common enough use case got moved into dedicated hardware (GPU, cryptographic acceleration instructions in the CPU) and anything uncommon is too hard for the average developer to write the Verilog/VHDL to implement.

We could but then we need software to take advantage of it, which means FPGA are like GPU in the early days without Direct X or OpenGL drivers sitting on top. Someone ( Microsoft ) will have to create a something that work across on both Xilinx and Altera.

Although I dont see that happening soon. Mostly because no one has the interest in doing so. What most likely will happen is that Apple are so far ahead in this game they started to take notice and work on something.

On Server it is very different though. Tiles and Chiplet will finally means FPGA can have their own node and optimisation while sitting next to CPU without all the complexity of trying to get them into the same silicon. Although the cost of specific software optimisation for specific task will likely means they only goes to HyperScaler.

To add to the other responses, I believe the end goal of "programmable specialized instructions" is being successfully explorer by other options than FPGA, ie the Raspberry Pi Pico state machines, for one example. Then there are also the hybrid CPU-FPGA models (or FPGA SoC) mentioned in the other replies, like the Zynq.

The problem for consumer devices is that FPGAs are power hungry; and consumers value battery life a great deal.

Reply on news.ycombinator.com