My guess: because FPGAs are slow compared to mainstream desktop CPUs and only make sense if you have massive paralelism. But then you'd need a massive FPGA which would be crazy expensive, plus you'd need a good way to handle throughput.
That, plus programming FPGA kind of sucks. The software tool chains are somewhere between 20 and 30 years behind the state of the art for software development.
Also, FPGAs can't be reasonably context-switched. Flashing them takes a significant amount of time, so forget about time-multiplexing access to the FPGA among different applications.
I could imagine some sort of API based queuing - say you have 2 "slots" you can program stuff on so if you play 8 k video you can have on flashed to video decoder while the other one can speed up your kernel compilation. If you then want to also use FPGA accelerated denoising on some video you recently recorded, the OS will politely tell you to wait for one of the other apps using the available slots to terminate first.
Since applications do all their rendering via the GPU these days, desktop multi-tasking requires reasonably time-sliced access to the GPU. GPUs have proper memory protection these days (GPU-side page tables for each process). That's big progress over 10 years ago.
True. But it's still far away from a unified approach you'd expect (as someone outside the field) in a modern OS. After all, one of the jobs of an OS is to abstract away access to underlying hardware as much as possible. Until we get some improvements here, my hopes are not very high for the FPGA domain.
Once partial reconfiguration works and the FPGA can access main memory directly I see a lot of use cases. Imagine applications reconfiguring the FPGA in the blink of an eye to optimize their own algorithms.
Why? To make an FPGA do what you want you need to be able to reconfigure it. If you have reconfiguration capability you need to have remote code execution. And in that case you have already lost.
As in, the FPGA would have to be carefully segmented so the accelerator couldn't be used to access memory it shouldn't have access to.
I don't think it would happen in a general purpose chip but I could see it happening in a smaller one like the exploits christopher Domas demonstrated against some embedded X86 cores.
Yes through the PCI bus not directly. You don't want to have that latency. You want a unified model. Like Intel GPUs that can access main memory, or the FPGA being another endpoint in AMDs infinite fabric architecture. That exists as well in SoCFPGA boards. But not in the mid or high performance segments.
Back when AMD released the first Opteron CPUs there was a vendor selling an FPGA that would plug into an Opteron socket along with the IP to implement HyperTransport in the FPGA.
Apart from the tooling woes others have mentioned (it's hard to get across how much FPGA tooling sucks compared to software tooling), FPGAs occupy a strange set of niches, but it's not clear how many are ones which would benefit the average PC or server. If you want raw memory bandwidth and FLOPs, a GPU is better (on speed, power, and price). If you want to evaluate complicated conditions and control flow, a CPU is better (in the same catagories). Because FPGAs are very power hungry and generally slower than the raw silicon, they only really give you more compute if what you want to compute is either far enough off the beaten path that some custom logic is much more efficient than the available instructions, and/or it benefits from a specific parallel datapath which doesn't easily fit on a GPU or CPU (GPUs being the best at embarrasingly parallel systems and modern CPUs being good at parallelising general purpose code reasonably well).
In practice you see FPGAs mostly in two areas: specialised embedded applications which benefit from heavy custom I/O and/or some efficient specific DSP but don't have enough volume to justify an ASIC design, or in accelerators for simulating ASIC design.
Because adding a layer of abstraction to silicon transistors makes for terrible performance and energy usage.
Every other year or so someone "rediscovers" FPGA and thinks this niche architecture is poised for a total revolution of how computing works, think drag&drop hardware and super fast custom everything. It never happens and it will never happen because customization, much like premature optimization, is the root of all evil and also just.. see the first paragraph.
Existing FPGA vendors made sure their products remained in a lucrative niche by maintaining full control over the development process for FPGA designs.
I could be totally wrong, though.