Raszterizálás máshogy

A raszterizálás is egy nehéz terepnek számít manapság, mivel a kijelzők felbontása nő, és ezzel a számításokat is egyre hatékonyabban kell megoldani. Ebből a szempontból az asztali grafika furcsa mód követi az ultramobil irányzatot. Egy korábbi cikkünkben írtuk, hogy ezek mennyire mások, és főleg ott jeleskednek, hogy kisebb fogyasztás mellett tudják megoldani ugyanazt raszterizációs feladatot.

Az AMD a draw-stream binning rasterizer konstrukciójával az úgynevezett overdraw problémát próbálja kezelni. Mint ismeretes, a mai grafikus motorok rengeteg olyan eljárást használnak, amelyek elsődleges feladata a felesleges számítások elkerülése. Ha egy nagy objektum több kis objektumot eltakar, akkor azok számítása felesleges, mert a képkockán nem fog plusz információt hordozni. Erre manapság rengeteg algoritmus létezik, így megoldottnak tekinthető a probléma. A következő dilemma a nem látható poligonok eltüntetése. Teljesen egyértelmű, hogy egy virtuális alakzatnak csak az az oldala számít, ami az adott nézőpontból látszik. Első körben a különböző backface culling eljárások valamelyikét kell bevetni. Ezek alkalmazásával elvethetők azok a háromszögek, melyek normálvektorai a nézőpont irányvektorával 90 foknál nagyobb szöget zárnak be.

Ezen a ponton már nagyon sok feladattól megkíméltük a grafikus processzort, de még mindig lesz olyan számítás, amelyiknek az eredménye később feleslegesnek bizonyul. Képzeljük el, hogy egy kisebb szikla részben elfed egy nagyobbat. Ilyenkor mindkét virtuális sziklát le kell modellezni, majd meg kell kezdeni a leképzést a nem látható poligonok eldobálásával. Igen ám, de a kisebbik szikla olyan háromszögeket is kitakar a nagyobb modellből, amelyek ugyan nem látszanak, de a backface culling nem tüntette el őket. Szakmailag korrekt megfogalmazással élve a háromszögek normálvektorai a kamera felé néznek. A klasszikus elvek szerint épített hardvereken ilyenkor nincs mit tenni, el kell kezdeni az objektumok textúrázását. Ezután sorra kell venni minden egyes háromszög pixelre vetített pontját, majd a megfelelő texelből, vagy texelekből – az alkalmazott szűrés szerint – ki kell számítani a képpont színét. Jelenleg a képkocka egy pixelére annyi képpont jut, ahány háromszöget érintett a pixelből kiinduló virtuális sugár. Nekünk persze csak annak a képpontnak az információja kell, amelyik a kamerához legközelebb álló háromszögből lett számítva. Itt jön a képbe a mélységpuffer. Az a számítás a helyes, amelyik esetén a mélységteszt a legkisebb Z értéket adja vissza, a többi számítás eredményét egyszerűen el kell dobni. A mélységteszt meggyorsítására a grafikus vezérlők számos speciális optimalizációt használnak, így a teljesítményigény minimális, viszont a felesleges számításokat sok esetben nem tudják elkerülni.

[+]

Ez a magyarázat segít megérteni az AMD megoldását, ugyanis új rendszerük a kiszámítandó képkockát azonos méretű, több pixelből álló binekre, azaz gyakorlatilag mozaikokra osztja. Ezek mérete konfigurálható aszerint, hogy az adott program számára mi az ideális, sőt a Vega 10 még a jelenet komplexitását is figyelembe tudja venni, és valós időben tudja átméretezni ehhez a mozaikokat.

A leképzés megkezdése előtt meg kell határozni, hogy mely háromszögek érintik az adott mozaikot, mivel a számítás szempontjából csak ezek a poligonok számítanak. A háromszögeket ezután mélység szerint egymás mögé rendezi a hardver, majd meg kell vizsgálni, hogy a mozaikban található képpontokból kilőtt virtuális sugarak mely háromszöget metszik először. Ha minden megvan, akkor – az alkalmazott szűrésnek megfelelően – el kell végezni a pixelek színinformációinak kiszámítását. Az eredmény lényegében mentes a felesleges kalkulációktól, mivel a nem látható háromszögek nem is lesznek árnyalva, illetve a munka is a lapkán belül marad, vagyis csak a mozaik végeredménye kerül kiírásra.

Ez a működési modell leginkább a TBDR dizájnra jellemző, de az AMD alkalmaz némi módosítást. Egyrészt a mozaikok relatíve nagyok, vagyis a számuk viszonylag kicsi lesz, illetve limitált méretű primitív halmokon dolgozik a rendszer, ami a cég szerint azért előnyös, mert így a komplex jeleneteknél jól menedzselhető a kivágás és a rendezés. Ennek viszont van egy hátránya is, ugyanis a relatíve nagy mozaikok nagy, lapkán belüli tárat igényelnek. Nyilván ha van elég tranzisztorkeret rá, akkor ez a módszer tényleg előnyös, ugyanakkor itt a kérdés sokkal inkább mérnöki jellegű, főleg úgy hangzik, hogy az erre szánt lapkaterületet el lehetett-e volna hasznosabban költeni. Erre valószínűleg sosem tudjuk meg a választ, mivel az ennyire specifikus információkat a cégek megőrzik maguknak.

Az AMD a hatékonyságról annyit árult el, hogy a gyakorlati méréseik szerint a DSBR mód a meghagyott normál raszterizáláshoz viszonyítva maximum 10%-os sebességelőnyt tudott felmutatni, miközben maximum 33%-kal csökkent a memóriabusz terhelése, és eközben semmit sem nőtt a rendszer fogyasztása.

A meghajtó oldalán többféle lehetőség van. Az alapértelmezett a DSBR tiltása, ugyanis ennek a működését az adott programra tesztelni kell; ebben a módban a hardver úgy működik, mint a korábbi generációs GCN-ek. Amennyiben egy adott alkalmazás jó eredményt ad DSBR-rel, úgy ezt a technikát rá lehet kényszeríteni, amit nyilván alkalmazásprofilban a legegyszerűbb megtenni. Végül van egy általános DSBR mód is arra az esetre, amikor a programnak direkt támogatása van a fenti újításra, ilyenkor működik ez a rendszer a leghatékonyabban. Azt kívülről nem igazán lehet megmondani, hogy egy adott alkalmazás melyik módot használja, ugyanakkor annyit tudni, hogy a legelső meghajtóban a legnépszerűbb, úgymond tesztjátékok többségére engedélyezve van.

A cikk még nem ért véget, kérlek, lapozz!