A grafikus vezérlők esetében mindig is fontos volt a háromszögek raszterizálása, hiszen ez a leképzés egyik alapvető eleme. Nem mindegy azonban, hogy a háromszög mekkora. Nyilván minél részletesebb a modell, annál több háromszögből áll, de ugyanakkor ennek nemcsak a geometria feldolgozása tekintetében van hatása a hardverekre, hanem a raszterizálásnál is, hiszen a végső kép pixelek formájában jelenik meg. A mai PC-s grafikus architektúrák teljesen megegyeznek abban, hogy a raszterizálást négyes pixelblokkokon végzik, ami rendkívül hatékonnyá teszi az egész feldolgozást, de van egy olyan hátránya, hogy ha az adott háromszög nem foglal el legalább 16x16 pixelnyi helyet, akkor a raszterizálás rengeteg felesleges számítást eredményez. Ennek a problémának az alapjairól régebben már írtunk, de teszt szintjén sosem vizsgáltuk a termékek viselkedését. Ennek főleg az az oka, hogy a raszterizálás hatékonyságának drasztikus visszaesése tízszeres lassulásban is megnyilvánulhat, vagyis értelmetlen a szituációt elemezni, hiszen egyetlen hardver sem működik úgy, hogy feldolgozhatók legyenek a nagyon apró háromszögek.
(forrás: G-Truc Cresation's) [+]
Christophe Riccio azonban úgy gondolta, hogy egy tesztet a probléma vizsgálata mégis megér. Bár túl sok értelme ugyan nincs, de ha már az említett programozó vette a fáradtságot, hogy adatokat gyűjtsön, tulajdonképpen miért is ne osztanánk meg ezeket? Az első teszt különböző méretű háromszögek raszterizálását vizsgálta. A kiindulási alap a natív felbontás volt (Full HD), majd kisebb méretű mozaikok jöttek (128x128, 64x64, 32x32 16x16 pixel és így tovább). Mivel az elméletet ismerjük, így nem meglepő, hogy az Intel Gen7.5, az AMD GCN és az NVIDIA Kepler architektúra jól érezte magát egészen a 16x16 pixeles mozaikig. Alatta a 8x8 pixeles szintnél még nem omlott össze a teljesítmény, de már számottevő, 40-70%-os lassulással kellett számolni. Ezt a terhelést az AMD GCN bírta a legjobban, míg az Intel Gen7.5 és az NVIDIA Kepler jobban megérezte. A 4x4 pixeles mozaikok esetében már sokszor lassabbak lettek a hardverek az optimális szinthez képest, és ez a lassulás drasztikusan folytatódott a még kisebb mozaikok mellett. Érdekes, hogy a 4x4 pixeles szinttől az Intel Gen7.5 viselkedett a legjobban, míg az AMD GCN a legrosszabbul. Persze ezen a szintén már közeledünk a mikropoligonok felé, így leginkább arról beszélünk, hogy hány másodpercig tart egy képkocka számítása, azaz a folyamatos sebességtől borzalmasan messze van mindegyik architektúra köszönhetően annak, hogy a raszterizálás hatásfoka 10% alá esik.
(forrás: G-Truc Cresation's) [+]
Persze nem csak olyan háromszögek léteznek, amelyek szabályosan lefednek egy négyzet alakú mozaikot, így Christophe Riccio megnézte a rendszereket téglalap alakú mozaikokkal is. A referenciaként szolgáló 16x16 pixeles mozaik mutatja a rendkívül magas hatékonyságot. A jellemző helyzetnek tekinthető 8x32 és 32x8 pixeles mérésnél nagyon érdekes, hogy az AMD GCN nem lassult semmit, amit valószínűleg az architektúrába épített tile-based load balancing rendszer magyaráz, ami pont a kritikus, de gyakorlatban még előforduló helyzetekben segít a raszterizálás hatékonyságának megtartásában. Ehhez hasonló technológiával az Intel és az NVIDIA nem rendelkezik, így a Gen7.5 és Kepler architektúrákon nagyon minimális lassulás érezhető, de ez még bőven elfogadható. Szélesebb mozaikok mellett a látható, hogy a GCN-be épített technika végzi a dolgát, de szélsőséges esetekben a hatékonyság így is a felére eshet, ami persze még mindig jobb a Gen7.5 és Kepler eredményeinél, de olyan szituációkról van szó, amelyet érdemes elkerülni.
(forrás: G-Truc Cresation's)
Érdekesség még az egy pixelnél kisebb háromszögek helyzete is. Bár logika ennek mérésében nincs, hiszen már egy pixel esetében is csak állóképek felvillanására van sebesség, de azért a hardverek technikailag megbirkóznak a feladattal, bár a képkocka kiszámítása akár egy percig is eltarthat.
A mikropoligonok ideje tehát még nem jött el, amit a gyakorlati tesztek is bizonyítanak. Viszont lassan érdemes lenne elgondolkodni egy olyan elképzelésen, amely 16x16 pixelnél kisebb háromszöget esetén sem rontja a raszterizálás hatásfokát. Ez részben a gyártók és az API-kat fejlesztő szervezetek feladata lesz. Bár kutatások ebben az irányban már a múltban is voltak, de ezek egyetlen hardverbe sem kerültek bele. Ez főleg annak köszönhető, hogy a PC-s grafikus API-k meglehetősen limitáltak voltak a kiadható rajzolási parancsok száma szempontjából, de az új generációs API-k ezt a problémát megoldják, így lassan tényleg csak a hardverek működése akadályozza majd a mikropoligonokat használó jelenetek leképzését.
