Az Intel lassacskán minden erőforrását a Skylake kódnevű processzor fejlesztésére koncentrálja, ami számos pletyka szerint elsőként tartalmaz majd olyan IGP-t, ami a Larrabee utódjának tekinthető MIC architektúrára épül. Ezzel kapcsolatban merültek fel pletykák, melyek között a rendszer működésének specialitása és egy saját fejlesztésű grafikus API is szerepel. Utóbbi elsődlegesen érthető, mivel a MIC architektúra működéséhez nagyon nem illik az a futószalag, amit a DirectX vagy az OpenGL használ. Ez persze lassan általánosan igaz lesz a mai új generációs grafikus processzorokra is, hiszen az NVIDIA Kepler és az AMD GCN architektúrát alapvetően limitálja a szabványos API-k működési struktúrája. Persze ettől még működőképes a rendszer, de az adott architektúrában rejlő technikai tudás kihasználatlan.

Természetesen az egyes architektúrák eltérő felépítésűek, így a limitáció mértéke is változó. A Kepler alapvetően nem lépett nagyon túl a szabványos API-k működési struktúráján, de a GCN már más mederbe evezett. Az Intel MIC rendszere viszont egy speciális eset, mivel hagyományos értelemben nem igazán nevezhető grafikus processzornak. Az eredeti Larrabee a textúrázáson kívül gyakorlatilag mindent emulált, ez a legfrissebb adatok szerint a Skylake-ben csak annyiban változik, hogy az Intel a tesszellálás emulálását sem tartja járható útnak (ami érthető), így erre lesz fixfunkciós egység, az alapvető futószalag többi lépcsőjének számításait azonban maguk a MIC magok végzik majd el, ideértve a raszterizálást és a blendinget. Ennek biztos lesz negatív hatása a teljesítményre, de valószínűleg az Intel ezt elfogadható kompromisszumnak tartja.

A MIC architektúra drivere is rendkívül speciálisnak ígérkezik. Igazából hagyományos értelemben nem is driverről van szó, hanem sokkal inkább egy programról. Információink szerint a működési struktúra az adott API-ig olyan lesz, mint a többi rendszeren, de ez alatt lesz egy specifikus leképző. Gyakorlatilag az adott program ezen a szoftveres rétegen fog futni, ami tulajdonképpen felfogható úgy is, hogy emulál az alkalmazásnak egy grafikus vezérlőt, és minden támogatott funkció ebbe a rétegbe lesz betáplálva szoftveresen. Amennyiben egy adott alkalmazás igényel valami új funkciót egy effekthez, akkor az Intel frissíti az úgymond GPU emulátort, és a hardver képes támogatni mindazt, amire aktuálisan igény mutatkozik. Természetesen létezik egy alapvető grafikus driver is ebben az infrastruktúrában, de ez elsődlegesen egy nagyon minimalista meghajtó, lényegében a kijelzők kezelésével kapcsolatos alapvető funkciók ellátására, hiszen a kiszámolt képet valahol meg kell jeleníteni.

Az előbbiek azért szükségesek, hogy biztosítsanak egy alapvető kompatibilitást a PC-re írt DirectX és OpenGL alkalmazásokkal. Ez nem könnyű, mert a MIC architektúra hatékony belső működéséhez mozaikos leképzés szükséges, hogy a rendszer minimális mértékben vegye igénybe az utolsó szintű gyorsítótár buszrendszerét. Nagyon leegyszerűsítve, az alapvető elv a mai hardverektől lényegében abban különbözik, hogy az aktuális grafikus processzorok előbb számolnak, és aztán dobják el azokat a kiszámolt eredményeket, amelyek a későbbiekben nem szükségesek. Az Intel rendszere előbb határozza meg, hogy mire van szükség, és aztán számol. Utóbbi tűnik logikusnak, de valójában ez nem ilyen triviális, ugyanis a pusztán a geometriai vázból meghatározni, hogy mi látszik csak a háromszögek sorba rendezésével lehetséges. Ez a procedúra eléggé számításigényes, vagyis a sebesség akár rosszabb is lehet a mai PC-s grafikus processzorok működéséhez viszonyítva, viszont a MIC számára fontosabb a belső buszrendszer kímélése. Nagyobb gond viszont, hogy a szoftverfejlesztők arra rendezkedtek be, hogy a hardverek az API-khoz hasonlóan izomból oldják meg a problémákat, vagyis az azonnali leképzésre építenek, így gyakorlatilag igen kevés olyan alkalmazás van a piacon, ami megmondja a hardvernek, hogy a jelenet számítása elkészült. Ezt a hagyományos feldolgozási elv mellett nem kell tudni, de a MIC architektúra számára fontos információ, mert esetlegesen úgy kell hozzáfogni a raszterizáláshoz, hogy a hardver nincs tisztában azzal, hogy az összes háromszög betöltődött-e. Szerencsés esetben a kép tökéletes lesz, de nem kizárható, hogy pont egy látható háromszög maradt ki a sorba rendezésnél és ezzel a raszterizálásnál, ami képhibát jelent.

Az állítólagos saját grafikus API valószínűleg szintén abba a bizonyos GPU emulátorba kapcsolódhat be, és alapvetően biztosít egy olyan futószalagot, amivel tökéletesen működik az architektúra. Persze bőven elképzelhető egy jóval direktebb kapcsolat a hardverrel, amivel jobb sebesség érhető el. Nyilván itt elég egy vékony driver a működéshez, de maga az elérés eléggé alacsony szintű, így a hardver tényleges működésével is tisztában kell lenni, ami az adott leképző megírása szempontjából több időt igényel. Elvben közvetlenebb hozzáférésre is lehet lehetőség, így OpenCL-ben például írható egy szoftveres leképző, de ez annyira időigényes, illetve annyira sok anyagi- és humánerőforrást igényel, hogy nincs túl sok indok amellett, hogy ebbe bárki belefogjon.