Az Intel Larrabee kódnevű projektjéről 2007 közepén kezdtek szállingózni az adatok. A fejlesztés elsősorban nem grafikus processzornak készült, azonban a Santa Clara-i óriáscég ezt a területet is be akarta húzni a rendszerrel. Az esetleges termékről évente jöttek az újabbnál újabb információk, mígnem 2009-ben az Intel a gyakorlatban is megláthatta mire képes az elképzelésük. A vállalat a 2009-es IDF-en demonstrálta is a rendszert működés közben, a prezentáció azonban nem durrant túl nagyot. Végül a 45 nm-es gyártástechnológiával készülő, Knights Ferry kódnevű lapkáról az elmúlt év végén derült ki, hogy nem kerül kereskedelmi forgalomba, ám a döntés oka máig nem ismert.
Szerencsére számos adat látott napvilágot a fejlesztéssel kapcsolatban, így mára lehet tudni, hogy a Larrabee miért pukkadt ki. A termék először a játékosok körében mérette volna meg magát, ám az előzetes eredmények alapján GPU-ként nem volt túl nagy teljesítménye. A hivatalos dokumentációkból be lehetett lőni a rendszer Unreal Engine 3 alatt mérhető sebességét, ami a HD 4890 és a GeForce GTX 275 körül alakult. Ez alapvetően nem lenne nagy probléma, azonban az ISC (International Supercomputing Conference) alkalmával lencsevégre került egy Knights Ferry lapkákat tartalmazó, 300 mm-es átmérőjű wafer, melyről látható, hogy összesen 85 chip fér rá. Némi számítással kideríthető, hogy a GPU mérete nagyon közel áll a 700 mm²-hez, ami borzalmasan nagy érték, főleg annak tudatában, hogy a jelentősen kisebb Juniper lapkával kellett volna versenyeznie. Természetesen a gondokat tetézi, hogy a Larrabee számos DirectX 11-es funkciót emulált, ami esetenként rengeteg teljesítménybe kerül, így előfordulhat, hogy a középkategória alját képviselő HD 5670 tempója sem lett volna tartható. Ez alapvetően megkérdőjelezi a termék életképességét, hiszen az előállítási költsége messze meghaladta volna a reálisan kiszabható árcédula nagyságát.
A Larrabee koncepciójával azonban már a kezdetektől fogva gond volt. Az Intel már a marketingnél hibázott, hiszen a médiában többnyire a játékosokat jelölték célközönségként, és olyan varázsszavakat durrogtattak, mint a valós idejű ray-tracing. Még házon belül is nyilvánvaló volt, hogy az ígéretek töredékét sem lehet tartani, így idővel a marketingesek is visszavettek, azonban ennél sokkal súlyosabb problémák is felütötték a fejüket. Ezekről a részletekről a gyártó nem beszélt, de a Larrabee bukása, és a teljes diszkrét GPU projekt ideiglenes szüneteltetése után Andrew Richards, a Codeplay elnök-vezérigazgatója úgy érezte beszámol a fejlesztéssel kapcsolatos érzéseiről.
A Codeplay a világ egyik vezető vállalata a fejlett fordítók, illetve a különböző programozási technikák területén, és számos technológiát kínálnak a gyártóknak a rendszerek programozásához. Az látható volt, hogy a Larrabee egy olyan hardver, ami szoftverből próbálja leküzdeni azokat az előnyöket, amiket az NVIDIA és az ATI-t felvásárló AMD az évek során felépített magának a GPU piacon. A koncepció lényegében rengeteg x86-os processzormag az adatok párhuzamos feldolgozására felkészítve. A rendszernek alapvetően már ezen a ponton harangoztak. Andrew Richards elmondása szerint általános nézet, hogy a grafikai számítások Szent Grálja az adatpárhuzamosság, ez azonban messze nem igaz. A mai GPU-k az API-kban kiépített futószalaghoz idomulnak, azaz konkrét feladatokra specializált chipek, melyek lényegében képesek az adatok párhuzamos feldolgozására. Persze ez csak az érem egyik oldala, hiszen nagyobb problémát jelenthet az, hogy a skálázható architektúra a gyakorlatban nem volt skálázható.
A Larrabee gyűrűs memóriabuszt alkalmazott a magok kiszolgálására, ez azonban nagyon szűkösnek bizonyult volna a Knights Ferry 32 darab processzormagjánál. Erre jelentett némi megoldást a Binned Rendering elvű feldolgozás, ám a jelentősebb problémák még így sem tűntek volna el. Az x86-os processzormagok nagyon mereven kezelik a memóriaműveleteket és a koherenciát. A cache koherencia lényegében azt jelenti, hogy ha egy mag kiír egy eredményt a memória egy bájtjába, akkor azt az adatot egy ciklussal később kiolvashatja egy másik mag. Ennek a megvalósítása sok kommunikációt igényel a processzormagok között, ám itt egy 32 magos rendszerről beszélünk, ami még a soknál is sokkal több kommunikációt jelent. Ez a probléma a központi processzoroknál is jelen van, azonban a programozók kezelik a nehezen kontrollálható helyzetet. A GPU oldaláról ez nem így működik, ugyanis a fejlesztők a feladatpárhuzamosságot tartják szem előtt, szigorúan definiált bemenetekkel, kimenetekkel és aszinkron memóriamásolásokkal. Ez a megoldás a játékok leprogramozásánál könnyebben járható út, és jól követhető, chippen belüli kommunikációt tesz lehetővé, amit természetesen a fejlesztőnek kezelni kell. Az adatpárhuzamos processzorok egy külön rendszert is alkalmaznak a memória olvasására (gather) és írására (scatter). Ennek segítségével az Intel a Larrabee esetében egy magon belül 16 szállal dolgozott, ami lehetővé tette, hogy egy utasítás 16 operációt hajtson végre egyszerre. Természetesen a 16 utas vektor elemei 16 különböző memóriacímre lettek kiírva, és az adatok behívásánál is ugyanennyi memóriacímről kellett betölteni a szükséges információkat. A chipen belül ez rengeteg kommunikációt jelent, ami a skálázhatóságra és a teljesítményre is rányomhatja a bélyegét. Ez annak köszönhető, hogy 16 különböző memóriacím betöltésével a gyorsítótárban 16 sor íródik felül. Tekintve, hogy mennyi processzormag dolgozik párhuzamosan igen nagy a valószínűsége a cache-miss lehetőségének, azaz az új adatok betöltésével az egyik processzormag akár el is vesztheti a feldolgozásra váró információkat, így újra be kell őket tölteni a memóriából. Természetesen a memória elérése lassú, így nagyon fontos ezeket a helyzeteket elkerülni.
A mai GPU-k bankokra osztják a gyorsítótárat, ami jelentősen redukálja a cache-miss lehetőségét. Persze a probléma nem tűnik el, de a bankokon belül nagy valószínűséggel nem lehet baj. Az információk szerint az Intel ezt nem tette meg, ami arra vezethető vissza, hogy az x86-os memóriaarchitektúrával ez a megoldás túl költséges. Ez azt eredményezi, hogy a Larrabee akkor van ideálisan kihasználva, ha 16 utasításonként van egy scatter vagy gather operáció. A mai viszonylatban többnyire 3 utasításonként kell ezzel számolni, azaz a rendszer általánosan kihasználatlan, ami rengeteg üresjáratot jelentett volna.
Ezek alapján nem meglepő, hogy a GPU-s projekt miért lett határozatlan időre elhalasztva, és az aktuális Larrabee eldobása is maximálisan érthető lépés.
Természetesen az Intel a HPC piac felé fordul, ahol nyilván más lenne az aktuális Larrabee szereplése, ám ezen a ponton is homokszem csúszott a gépezetbe. A hardver fejlesztésénél több időt vesz igénybe a szoftveres háttér biztosítása. Erre az NVIDIA időben rájött, így a CUDA platformon keresztül teljes támogatást biztosít a Fermi architektúrára épülő Tesla rendszerekhez, azonban az Intel kezében nincs meg a szoftveres háttér a Knights Ferry kiadásához. Persze a cég gőzerővel dolgozik a hátrány ledolgozásán, így a jövőben akár fordulhat is kocka a HPC rendszerek esetében, addig viszont a Fermi is fejlődik, és az NVIDIA nem fogja könnyen megadni magát, hiszen elsőszámú szempontjuk a Tesla piaci pozíciójának megtartása, sőt erősítése.
