Intel Larrabee: Potential Disruptive Technology

One of the major announcements at last week's SIGGRAPH conference was the Intel paper presenting their new graphics architecture.  I say graphics, however it doesn't take much imagination to realize that a powerful many-core architecture like Larrabee has general-purpose and special-purpose computational potential beyond graphics specifically.

I am not a graphics processing expert, I will be the first to assert.  For a technical write-up on what Larrabee is and is not, I would refer you to the excellent Ars Technica article on the subject.  What I do know is how to spot disruptors when they surface, and this announcement has the potential to become very disruptive.

Most of us are familiar with and already use multi-core Intel systems.  When Intel discusses specialized hybrid many-core architectures (which will roll out as products in late-2009 or early-2010), they are referring to taking tasks typically relegated to specific Graphics Processing Units (GPUs) and running them through their new architecture, so you gain the benefit of scaling performance based on the number of cores beyond fixed-architecture GPUs, and potentially the secondary benefit of highly-flexible many-core computational engines sitting in each 'Intel-inside' box.

Now, the graphics industry is highly specialized and segmented around the black art of extracting maximum graphic quality from each manufacturer's GPU.  This adds extra cost to development of any graphically-intensive application, be it games or rendering or something similar, as each GPU needs to be coddled and held for maximum compatibility and performance.  By taking this highly-specialized group of practitioners and injecting an architecture like Larrabee beneath their GPU, it MAY (and I stress MAY) obviate the need for the purchase of the specialized GPU altogether.

This is where Intel's pervasive footprint with manufacturers of computers plays to their advantage.  If they can successfully infect their downstream computer manufacturers with this architecture, and OS vendors have access to (the notoriously open) Intel drivers, then driver-compatibility for applications becomes less of an application specific function and more of an OS function, abstracted from applications.  At that point, the combination of the chipset and the OS will optimize the processing for the application. 

This is somewhat true today with regards to OS included components for the dominant GPUs, however any Windows Vista early-adopter will be the first to tell you that even the dominant GPU and OS players are prone to paralyzing incompatibility issues.

So, as a prediction, this will end up being a flattener, taking margin once allocated to custom GPU companies like nVidia and re-allocating it to Intel as they attempt to assimilate this function closer to their domain.  Initial deployments will inevitably be frought with problems of compatibility as the developer community learns how to best maniplulate the products and architecture, then things will stabilize and we'll see entirely new levels of graphics in gaming and rendering.

To return to my earlier disclaimer, I am not a graphics expert.  I do know that when infrastructure providers like Intel, Cisco, and Microsoft assimilate functionality from value-added functions into their core product offerings, it typically does not bode well for the specialized industry.  It happened with languages, military formations, and countless other technologies, and it's going to happen this time as well.