It's remarkable how little we've seen from that acquisition. It's perfectly possible that Intel has butchered the acquisition the same way they have with many others.

The two huge companies being merged is more often considered fail than otherwise.

> a 2004 study by Bain & Company found that 70 percent of mergers failed to increase shareholder value. More recently, a 2007 study by Hay Group and the Sorbonne found that more than 90 percent of mergers in Europe fail to reach financial goals.

http://edition.cnn.com/2009/BUSINESS/05/21/merger.marriage/

Especially when the merge should be deep and involve engineering teams with different cultures to join and work together on the product. So I'd consider the release of first Xeon+FPGA after 3 years past acquisition as a somewhat success.

Billion Dollar Lessons by Mui & Carroll goes through a lot of these grand strategies and demonstrates how much of a bonfire they turned out to be.

The Xeon + FPGA that was actually underway before the acquisition and based on pre-acquisition technology (Arria 10).

Computer hardware has a very long lead time between product concept and metal-in-your-hand. Combined with the pains and huge initial slowdown of a megacorp purchasing a medium-corp, I think the real fruits of that acquisition are yet to be seen. I bet it took at least a year just for management to get their bearings on straight.

I would have guessed additional lead time for Altera to move their designs from TSMC to Intel process, but it looks like Altera has been planning to fab on Intels 14nm since 2013[0].

[0]http://chipdesignmag.com/display.php?articleId=5215

But CPU+FPGA will forever be a tiny niche, right? I don't see any path where mainstream programs get a boost from FPGA.

Not at all. Specialized coprocessors are mainstream actually - from network cards offloading to small chip in every iPhone, and for a reason.

The obvious way forward is universal specialized coprocessors, reprogrammable for the task(s). Better if tightly integrated with the memory, buses and CPUs.

The weak side of FPGA historically is programmability and especially the tools. But since the interest for FPGA is growing exponentionally in open-source community in recent years, things may change.

And by the way, 10 years ago you would say that exactly 'niche' words about GPU.

Specialized coprocessors are super common but they're basically all ASICs with nary an FPGA to be found. In theory you could have reconfigurable co-processors on a mainstream chip but nobody does that - partially because the latency involved in reconfiguring the FPGA makes it a losing proposition in most cases.

There are uses for FPGAs where there's enough money at stake for the hardware development but the number of units is small - stuff like high frequency trading or many defense roles. Or in the development of new hardware. But it's pretty niche.

How is every consumer device with a display "niche"?

Dedicated GPUs were not required historically to drive displays, and this was done by the CPU instead.

Similarly, we’re finding more functions we can take away from the CPU and migrate to dedicated circuitry (FPGAs) that can handle those tasks more efficiently than the CPU can.

dedicated circuitry != FPGAs.

GPU's avoid the overhead of FPGAs while still retaining a lot of flexibility.

Because they were all 2D. And the idea that GPUs would be used for mobile computing was not obvious.

Maybe 25 years ago. 10 years ago they were commonplace. Intel shipped integrated 3d graphics by no later than 1999:

https://en.wikipedia.org/wiki/Intel_810

Lol I don't know who bought that. Anyone who wanted 3D was buying Voodoo, RIVA TNT or ATI RAGE. Everyone else was happily 2D and running Word 95.

But, to clarify, I was speaking of consumer/mobile. The original iPhone was quite revolutionary for having a decent PowerVR graphics chip. High end symbian phones just had a CPU. See for example https://en.wikipedia.org/wiki/Nokia_6110_Navigator or https://en.wikipedia.org/wiki/Motorola_Razr2

Even though GPGPU was already big in 2008, people still thought of it as a difficult to use coprocessor for big compute jobs. Much as people consider FPGAs now.

I didn't highlight it as a desirable 3d processor, I pointed it out because 3d was essentially becoming default at that point.

And the first iPhone shipping with a powerful graphics chip is a counter to your argument that the future of mobile wasn't clear. The people with the ideas wanted a graphics processor.

The fact that the entire industry apart from Apple (a computer company, not a phone/device company) were completely ignoring 3D exactly shows that it was NOT obvious or clear. After Apple demonstrated the potential it became clear.

Okay, I should have clarify the 'niche' thing 10 years ago was not GPU per se, but of course GPGPU, the GPU as a specialized coprocessor for general purpose computation, not restricted to graphics processing and output.

That depends what you mean by mainstream. These days the cloud data centre is a mainstream market for hardware vendors. In that environment FPGAs can make sense. They might have advantages in throughput, latency, power consumption, security (no spectre), reliability (no software updates). For example, Microsoft use them for Azure virtual networking, machine learning and something inside Bing. You can imagine a world where every blade server has an FPGA. In fact, you can imagine a world where many blade servers have an FPGA and only a small support CPU.

You can spin up an FPGA-accelerated EC2 instance right now. There are a few highly specialised applications where every scrap of performance matters, but for the most part the software development costs are prohibitive compared to just spinning up more CPU or GPU instances.

https://aws.amazon.com/ec2/instance-types/f1/

There are some interesting ideas about programmability, like automagically offloading some computation parts to FPGA.

http://conal.net/blog/posts/haskell-to-hardware-via-cccs http://conal.net/blog/posts/circuits-as-a-bicartesian-closed... https://github.com/conal/lambda-ccc/blob/master/doc/notes.md

The software needed to drive them needs to become much better (documented, ergonomics, everything) before that will be a realistic option.

As far as know there are zero applications on the client or desktop side that can take advantage of FPGA.

There's this: https://docs.microsoft.com/en-us/azure/machine-learning/serv...

I can see there being a market for that. The reason nobody uses FPGAs at the moment is because nobody has them outside of specialized applications.

If Intel can release a CPU with a built-in FPGA and everyone has one, software developers will take advantage of them. I can see stuff like video editing programs, compression algorithms, etc taking advantage of that.

That's nonsense. PCI/PCIe FPGA accelerator boards have been around for ages, mostly used by the finance traders and for machine learning/math-intensive computations before cheap GPUs with much simpler programming models (no need to write e.g. matrix multiplication in VHDL/Verilog anymore) like the various programmable shaders, CUDA and OpenCL have pretty much relegated them into obscurity.

FPGA is great if you need to talk to some hardware very fast/on many pins. E.g. something like a network router where you are shuffling packets between many high speed interfaces. Or doing a lot of measurements/interfacing a bunch of high speed sensors.

But not for general purpose software - GPUs are both faster, easier to develop for (and with good tooling) and much cheaper for doing that today.

Looking forward to that, without 'you need to buy Skylake CPU that is just as fast as the one you had before to get H265 decoding'. Good riddance.

The other thing is that they're a nightmare to programme and they're expensive!

Yes, but speedup can be huge. For example, for NFA processing, using (a couple of) 2W FPGA against 200W GPU "GPUs underperform FPGA by a factor ~80-1000x across datasets" http://people.cs.vt.edu/~xdyu/html/ics17.pdf

The state transition table is encoded in logic for FPGA and as global memory table for GPU. Why didn't they try to encode state transitions as code on GPU?

Also, did they try to use enhanced locality introduced by processing several streams on GPU? E.g., if you keep states sorted as for tuple (state id, stream id) for all your streams, you may get more memory-controller friendly access pattern. I haven't seen mentions of that technique (which MUST be considered after Big Hero 6 [1] - they used that technique to never miss caches in whole movie rendering process). Big Hero 6 is 2014, the paper is 2017.

[1] https://en.wikipedia.org/wiki/Big_Hero_6_(film)

I really do not like papers like one linked by you. One system gets all of the treatment while other ones get... whatever is left.

I guess have they tried to use these techniques for GPUs, they would get performance gap that is much less than reported.

Today they are. Programming can be made easier with large frameworks. Cost can be reduced with higher volume.

at SC and CUG this year the main focus was that in less than 10 years IPC improvement is going to go away (I am not sure where IPC improvement was in the last three years). Anyway, the next step is to make CPUs as much heterogeneous as possible like a SOC. Both Intel and AMD are going there but we need to sit and see which direction is going get the momentom like what nVidia has done.

The new ARM AI processor looks like it'll play well in this space for some workloads:

https://www.nextplatform.com/2018/08/22/arm-stands-on-should...

Not a thing for everyday desktops, but looks like compute competition is er... heating up. :)