A számítógépes grafika egyik nagy problémája a pixelek árnyalásának hatékony megvalósítása. Erre már számtalan megoldás született, hiszen az egyértelmű, hogy a végső képen nem megjelenő adatok számítására felesleges erőforrást pazarolni. Ezt azonban könnyebb mondani, mint megvalósítani, mivel a leképzés folyamán a kivágási fázisok lefuttatása után még mindig szép számmal lesznek olyan részletek, amelyek a végső képen nem látszanak, de nem lehet megfeleltetni rájuk egy egyértelmű szabályrendszert, így kivágni sem lehet a számításokat. Persze a többletterhelést okozó kalkulációk mennyisége a jelenet komplexitásától függ, de mindig jó példa a kis szikla és a nagy szikla esete. Előbbi kitakar az utóbbiból egy részletet, ami a pixelek számításánál már kellemetlen dolog, mert a kitakart háromszögek a leképzés szempontjából egyértelműen érdektelenek, de nem lehet kivágni azokat.
Az alapproblémára megannyi megoldás született az elmúlt évek során, de mindegyikre jellemző, hogy van valami limitációjuk, ami megnehezíti az alkalmazásukat. A manapság bőszen használt kivágási algoritmusok viszont így is igen nagy segítséget jelentenek, mivel igen egyértelmű szabályrendszert használva rengeteg többletterheléstől mentik meg a rendszert. Felesleges számítás azonban még így is lesz, nem is kevés. Ezek ellen több módon lehet védekezni, így például az egyik megoldás egy mélységteszt még az árnyalás megkezdése előtt és az objektumok sorrendben történő kirajzolása, kezdve a kamerához legközelebbivel. Tipikus problémát jelentenek viszont az átlátszó felületek, hiszen a kivágás során még a rendszer nem tudja, hogy szükség van az átlátszó felület mögötti háromszögekre is. Ezekre is vannak különböző trükkök, de a mai grafikus API-k struktúrájának sajátossága, hogy azonnali rajzolással dolgoznak, így nem törődnek a jelenetben szereplő objektumokkal. A problémák kivédéséhez szükséges trükköket tehát teljes egészében a grafikus motornak kell megoldania, és minden szituációra értékelhető minőségű működést kidolgozni nem kellemes feladat. Sokszor inkább a művészi munkát kell limitálni, mivel az adott rendszer nem képes bizonyos jelenetek helyes leképzésére, ami az adott játék dizájnját kidolgozó szakemberek rémálma.
Az ARM az első bekezdésben felvázolt problémára megpróbál egy hatékonyabb megoldást kínálni, ami az FPK névre hallgat. Ez a Forward Pixel Kill rövidítése, a technológia pedig a Mali-T624, -T628 és -T678 sorozatú fejlesztéseknek lesz a része. Az FPK arra az alapötletre épít, hogy az a szál, ami az adott pixelt árnyalja menet közben megsemmisíthető. Ezt persze a mai hardverek nem teszik meg, mert fogalmuk sincs, hogy melyik számítás eredménye hasznos és melyiké haszontalan. Az FPK technológia azonban itt jön képbe. Ha egy folyamatban lévő számításról bármikor kiderül, hogy értelmetlen lefolytatni, mert az eredménye a megjelenített kép szempontjából lényegtelen lesz, akkor azt a szálat a rendszer konkrétan megszünteti. Opciós lehetőség a fejlesztők számára a futószalag kiegészítése egy FIFO pufferrel, ami megnöveli az FPK hatékonyságát, hiszen még a számítások megkezdése előtt is kivégezhetők a nem szükséges szálak.
Az ARM szerint az FPK olyan hatékonysággal dolgozik, mintha a grafikus motor a kamerától távolodó sorrendben rajzolná ki az objektumokat, és ezzel elkerülné a felesleges számításokat. Az FPK előnye azonban, hogy nem szükséges a motorba az ehhez szükséges rendezést beépíteni, így az erőforrást sem igényel, amivel fogyasztás takarítható meg. Ennél is nagyobb előny, hogy az FPK-val az átlátszó felületek kezelése sem jelent majd problémát, azaz a teljesítményigényes trükköket el lehet felejteni.
Az FPK technológia az ARM Mali-T624, -T628 és -T678 sorozatú IGP-ken belül automatikusan aktív, viszont a kiemelten hatékony működéshez már a grafikus motoron belül is szükség van némi módosításra. Az FPK egyébként licencelhető az ARM-tól, így a konkurens cégek is beépíthetik a rendszert a későbbi fejlesztésekbe.
