Nyní je čas v renderovací cestě pokročit dál, a to k „Render Back-end“ částem, tedy místu, kde se z té hromady předpřipravených dat počítá a sestavuje to, co uživatel vidí na monitoru.

Nejprve jsou jednotlivé „dlaždice“ (části obrazu vzniklé rozdělením v duchu tile-based renderingu) nataženy do vyrovnávací paměti. Již zmiňované čtyři thready nad jedním výpočetním jádrem pracují na stejném souboru dat ve společné paměti, viz diagram.

Na něm jsou vidět čtyři výpočetní vlákna, kde jedno pracuje jako setup, který vezme veškerou geometrii z přidělené dlaždice a vytvoří dílčí fragmenty pro další zpracování. Zbývající tři vlákna pak tyto fragmenty dostanou na svém vstupu (možná přebírají rovnou skupiny fragmentů po 4 až 16, opět jen dohad), zkontrolují jestli budou na výsledné scéně vidět (Early-Z), provedou shaderové operace (načtou textury a vykonají příslušející shaderové programy), provedou anti-aliasing a alpha blending.

Na tento postup se zatím dá pouze usuzovat ze střípků dostupných informací. Jakmile přijde Larrabee na trh, tak si budeme moci toto vše buď potvrdit, nebo vyvrátit a vůbec nejlépe by se to dělalo, kdyby Intel skutečně uvolnil zdrojový kód softwarového rendereru.

Díky tomu, že nejde o hardwarovou implementaci s pevně danými funkcemi, může Larrabe nepoužívat klasický alpha blending a místo něj využít layered transparency za přispění seznamu fragmentů uchovávaného spolu s informací o Z souřadnici.

Navíc lze počítat s Irregular Z-buffers (nepravidelně rozložené Z buffery, které lze využít pro lepší shadow mapy a vyhnout se tak artefaktům v renderované scéně) a dalšími komplexními datovými strukturami, které mohou být na Larrabee implementovány, zatímco klasická GPU toto jednoduše nemohou nabídnout. Klíčové bude, zdali toto začnou vývojáři využívat. I zde jim Larrabee poskytuje plnou volnost při psaní kódu a mohou tak implementovat prakticky jakoukoli metodu, kterou si vymyslí.

Vědci Katedry počítačových věd a University of Texas a Texas Advanced Computing Center k tomu říkají následující: Jednou ze základních úloh v 3D grafice je problém viditelných povrchů, problém efektivního nalezení prvního bodu mezi paprskem a souborem povrchů. Tento problém se typicky řeší (počítá) buď pomocí Z-buffer algoritmů, nebo raytracingem (oboje jsou metody popsané před více než 30 lety). Téměř veškeré moderní grafické systémy používají Z-buffer implementovaný specializovaným hardware. Algoritmy pro realtime rendering jsou pevně spjaty s grafickou architekturou, na níž jsou implementovány a organizace této architektury se za posledních 15 let téměř nezměnila. Výsledkem je, že Z-buffery nadále přetrvávají navzdory zkušenostem, dle kterých lze použít daleko efektivnější algoritmy produkující vyšší kvalitu obrazu, pokud budou implementovány v dostatečně výkonné formě. Irregular Z-buffery proskytují něco z flexibility raytracingu (mimochodem v souvislosti s Larrabbe se vám přece musí raytracing honit hlavou celou dobu, co tento článek čtete) za současně výborného zachování výkonu charakteristického pro klasické Z-buffery. Irregular Z-buffery řeší problém viditelných povrchů, sdílení paprsků, jednotného zdroje a různých směrů. V podstatě jsou univerzálnější než klasické Z-buffery, kde směr paprsku musí následovat daný vzor. Nejsou však tak univerzální jako samotný raytracing, kde jak směr paprsku, tak jeho původ jsou zcela nezávislé a mohou tak sloužit k otestování viditelnosti libovolného bodu scény z libovolného jiného bodu scény.

Ale v tu chvíli opět musíme zmínit riziko nedodržení zpětné kompatibility. K čemu vám bude skvělý, takřka dokonalý kód, když jej dokáže spočítat pouze jedna grafika, která je navíc na trhu pouze velmi krátce, zatímco obě zaběhlá konkurenční řešení to neumí a nechat to v takových případech počítat klasickým CPU nelze, protože na to není dost rychlé? Herní vývoj je svázán léty tradice a proti takovým překážkám se bojuje těžko (zejména třeba u her, které jsou současně kompilovány pro Windows i Xbox 360).