Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Gears Up for FPGA Push

nextplatform.com

Post reply on HN
Print view View original

51–60 of 112 posts

Re: Intel Gears Up for FPGA Push

#51

Post by davrosthedalek »

booblik wrote: post #37
katastic wrote: post #10

I've honestly been waiting for this since for YEARS. I've had a vision for "the future of computing". FPGAs that reconfigure themselves ( This would be hard for a single person, but any large company could handle making this. You can even do it with off-the-shelf FPGAs. The biggest problems are 1) bandwidth. The "macro" function size needs to be bigger than the latency hit you take for asking the FPGA over computing…

> As CPUs are designed for one thing "few, large, complex cases" while FPGAs are perfect for many, parallel simple cases" even more than a GPU. FPGAs are quite good at parallel simple cases, that is correct, but they would lose to GPUs in performance/watt in most cases. Where FPGAs really shine is in parallel complex, non-uniform cases, especially cases that don’t map well to the classic CPU instructions, but can eas…

Especially if the level of parallelism isn't too large, or if the memory bw requirement for each is low. The memory bandwidth of FPGAs is comically small typically compared to GPUs if it has to go to off-chip memory. Internal memory is limited to a couple MBit typically.

Re: Intel Gears Up for FPGA Push

#52

Post by psykotic »

burntrelish1273 wrote: post #13

The biggest problem with reconfigurable computing is it's either an afterthought, tools are too narrow/proprietary or an extra add-in card. Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles (ie process context), and then future AI-enabled optimizing compilers could incrementally profile and accelerate applications w…

> Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles

LUTs are implemented as a cascade of muxes that are controlled by local latches that are set at configuration time through a scan chain. Scan chains are key to letting you configure all these LUT control latches across the whole chip in an area-efficient manner, but there's a severe time vs area trade-off since you're essentially configuring one LUT control bit (a vanilla 6-LUT has 2^6 = 64 control bits) per scan chain cycle per scan chain. FPGAs already suffer ~30x area overhead for LUT logic compared to equivalent ASICs, so adding a lot of additional area to enable much faster reconfiguration seems like a tough sell. Matrix addressing as used in DRAMs and LED/LCD displays is another sweet spot on the time vs area trade-off curve. Not sure if anyone's ever done an FPGA using that as the configuration topology, but it'd probably make a fun dissertation topic.

Re: Intel Gears Up for FPGA Push

#53

Post by rjsw »

burntrelish1273 wrote: post #13

The biggest problem with reconfigurable computing is it's either an afterthought, tools are too narrow/proprietary or an extra add-in card. Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles (ie process context), and then future AI-enabled optimizing compilers could incrementally profile and accelerate applications w…

Intel do have ARM+FPGA products already from Altera, as do Xilinx.

It will be interesting to see if Intel replaces the ARM CPU with a variant of x86.

Re: Intel Gears Up for FPGA Push

#54

Post by imtringued »

pm215 wrote: post #22
StillBored wrote: post #16

Earlier quoted context omitted.

That is pretty much the ARM and POWER problem too, they think they can grow in new markets with these hugely expensive machines in quantities of ten racks. Both would have significantly more traction if they offered a reasonable desktop class machine, but they don't seem to be able to do it. For some reason there are dozens of RPi type devices but making a $200-$300 device with a reasonable set of expansion ports (sa…

The underlying problem here is that the cost of making an SoC is enormous. So to make, say, an ARM desktop class machine you have only a few choices: 1) Make your own SoC designed for the purpose. You can tailor it to meet your requirements precisely, but given the low volumes you'll be selling, your system will be at least $10,000 a box, likely more. 2) Use a designed-for-mobile SoC. This will hit your $200-$300 pri…

>The underlying problem here is that the cost of making an SoC is enormous.

Broadcom designed a custom SoC for the Raspberry Pi 3 and everything still runs over USB 2.0.

Re: Intel Gears Up for FPGA Push

#55

Post by makomk »

tim-- wrote: post #38

What's new here anyway? Intel bought Altera, and Altera have had development kits similar to this for a long time. What is the price of the new FPGA add-on cards? That is what will make the difference here for a 'new push'.

The new thing is that the embedded hard CPU core is some flavour of Xeon rather than ARM or MIPS.

Re: Intel Gears Up for FPGA Push

#56

Post by imtringued »

dragontamer wrote: post #26
pratumlabs wrote: post #6

Earlier quoted context omitted.

One of the key benefits of Intel's solution is that the CPU and FPGA share the same RAM, avoiding the O(N) cost of moving data to/from the devices. This type of a zero-copy transaction can enable very high performance applications compared with dedicated discrete cards.

AMD already does "Zero Copy transfers" (the on-chip cache!!) with its "Fusion" APUs (ex: A10-7850K) for CPU > GPU. I'm not really seeing loads of people taking advantage of the feature however. The platform is cheap, the technology is available but its just way too weird an architecture to become mainstream. There are numerous benefits: the CPU can create a linked list or graph, and the memory will still be valid on…

>I'm not really seeing loads of people taking advantage of the feature however. The platform is cheap, the technology is available but its just way too weird an architecture to become mainstream.

AMD sells a consumer product. For most consumers even a smartphone offers enough CPU and GPU performance. The content producers who care about performance usually buy the best CPU and GPU. HSA isn't available on AMD's Ryzen or Threadripper processors.

Intel is trying to sell to datacenters where performance or energy efficiency is a major selling point.

Re: Intel Gears Up for FPGA Push

#57

Post by Gracana »

rjsw wrote: post #53
burntrelish1273 wrote: post #13

The biggest problem with reconfigurable computing is it's either an afterthought, tools are too narrow/proprietary or an extra add-in card. Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles (ie process context), and then future AI-enabled optimizing compilers could incrementally profile and accelerate applications w…

Intel do have ARM+FPGA products already from Altera, as do Xilinx. It will be interesting to see if Intel replaces the ARM CPU with a variant of x86.

Would anyone use it? I wouldn't. Intel's embedded offerings are weak and tend to get cancelled.

Re: Intel Gears Up for FPGA Push

#58

Post by simias »

AriaMinaei wrote: post #43

In the case of Lisp and Smalltalk and other highly dynamic languages, would these on-die FPGAs open new compiler optimisation opportunities?

The problem is that tailor-made FPGA designs won't run nearly as fast as a modern ASIC CPU. That's why for instance FPGA emulators are not more common, for older hardware software implementations are accurate enough and manage to run in realtime so the additional cost and complexity of FPGAs is not warranted.

For more modern hardware software implementations can't reach absolute accuracy in real time but FPGAs big and fast enough to handle these designs are prohibitively expensive (if they even exist in the first place). That's why FPGA GameBoy emulators are not popular and you probably won't see a FPGA PS3 emulator any time soon (unless the pricing changes dramatically in the near future).

FPGAs shine when you need to process very high throughput data with low (or at least constant) latency or for special-purpose algorithm with no hardware acceleration available on CPU or GPU (video codecs, crypto, computer vision etc...). But in general when an algorithm becomes popular enough (AES, SHA-256, H264...) hardware support is backed into the ASIC eventually with much better performance and power consumption than a FPGA.

I see a potential for FPGAs in CPUs for professional applications if you want to process big datastream without having to rely on external hardware. For instance I work in broadcast video transmission where we routinely handle uncompressed HD or even 4K streams, being able to prototype directly on my workstation's CPU would be pretty cool.

As for general purpose programing language optimization I have a hard time imagining what it would look like. The problem is that you don't code for a FPGA the way you code for a CPU. To put it very simply on the CPU serial is cheap while forking and synchronizing threads is expensive. On an FPGA it's basically the other way around. Automatically transforming one form into the other automatically in a compiler or JIT sounds very much non-trivial. Maybe I just don't have enough imagination.

Re: Intel Gears Up for FPGA Push

#59

Post by dragontamer »

imtringued wrote: post #56
dragontamer wrote: post #26

Earlier quoted context omitted.

AMD already does "Zero Copy transfers" (the on-chip cache!!) with its "Fusion" APUs (ex: A10-7850K) for CPU > GPU. I'm not really seeing loads of people taking advantage of the feature however. The platform is cheap, the technology is available but its just way too weird an architecture to become mainstream. There are numerous benefits: the CPU can create a linked list or graph, and the memory will still be valid on…

>I'm not really seeing loads of people taking advantage of the feature however. The platform is cheap, the technology is available but its just way too weird an architecture to become mainstream. AMD sells a consumer product. For most consumers even a smartphone offers enough CPU and GPU performance. The content producers who care about performance usually buy the best CPU and GPU. HSA isn't available on AMD's Ryzen…

> The content producers who care about performance usually buy the best CPU and GPU. HSA isn't available on AMD's Ryzen or Threadripper processors.

Raven Ridge will be based on Zen CPU cores and Vega GPU cores. But naturally, Raven Ridge will be slower than Threadripper because the GPU will take up some space (that otherwise would have been additional CPU cores).

Rumored specs of Raven Ridge APU is 4 CPU cores and 11 GPU Compute Units. In contrast, Threadripper is around 16 CPU Cores and Vega 64 is 64 GPU cores, separated by a PCIe x16.

So basically, its the price you pay for sticking so many things onto a single package. There are thermal limits, as well as manufacturing limits (ie: practical yield sizes) to how large these chips can be.

If you want the best of both worlds, like an EPYC CPU with Vega 64 or a high-end NVidia Pascal / Volta chip, you'll need to buy a dedicated GPU and a dedicated CPU. True, a hybrid chip like Raven Ridge (or any of the AMD HSA stuff) has benefits with regards to communication, but the penalty to CPU speed and/or GPU speed seems to be huge.

-----------

I personally expect that if any "mainstream" FPGA solutions come out, they'll be connected to the PCIe and not merged into the CPU. There seems to be just too many heat and manufacturing issues to make a merged product compared to the standard PCIe x16, which is quite fast.

Alternatively, certain tasks (like Cryptography) can be accelerated using dedicated instructions, like the Intel AES-NI instruction set. Or Intel's Quicksync H.264 encoding solution. Fully Dedicated chipspace (like AES-NI) is way faster and more power efficient than FPGAs after all.

Re: Intel Gears Up for FPGA Push

#60

Post by Boothroid »

nimish wrote: post #44

Tooling tooling tooling. FPGA hardware is cool but the tooling fucking sucks. Like stepping back into the time where you needed to pay thousands of dollars to get decent compilers and debuggers. The ability for anyone to develop software for CPUs at zero-cost is an amazing freedom. You literally cannot do that on certain fpgas--not only do they cost thousands, so do the tools to actually create a working design. Unti…

I have an iCEstick sitting in a drawer, for which some pretty amazing open source tools are available: http://www.clifford.at/icestorm/

I wish I had the time to play with it!

Post reply on HN