A média egyre inkább ki van éhezve az új VGA-kkal kapcsolatos pletykákra, így gyakorlatilag már az olyan dolgokról is írnak, amelyeket egy YouTube videó közöl. A legfrissebb anyagot a Coreteks videója szállította, amely egy traversal coprocessorral magyarázta az utóbbi időben feltűnt hűtőrendszert. Utóbbi állítólag az egyik új GeForce-on kap majd helyet.
A fő kérdés az volt, hogy miért ilyen fura kinézetű az új hűtő. Occam borotvája alapján azt lehetne mondani, hogy így hatékony, de nyilvánvalóan ez nem hozna sok kattintást a konyhára, anélkül pedig minek fenntartani a YouTube csatornát. Ilyen formában jöhetett is a traversal coprocessor ötlete, amely a videó alapján a nyomtatott áramköri lap GPU-val ellentétes oldalára kerülne, és ezzel az NVIDIA a sugárkövetéshez való hardvert kivenné a grafikus vezérlőből.
De ez miért is lenne jó? Abból a szempontból van értelme, hogy így nem kellene sugárkövetés nélküli kisebb dizájnokat tervezni, ugyanakkor van egy nagy ellenérv is, mégpedig az adatmozgás.
Egy sugár útja
Bármilyen sugárkövetést biztosító megoldást veszünk is, az adatmozgás tekintetében a hardverek gyakorlatilag egy kaptafára épülnek. Persze a DirectX Raytracing 1.0-s és 1.1-es verziója az ütemezés tekintetében eléggé eltérő, de a grafikus vezérlő eszközszintjéhez közel, az adatok biztosítása során kvázi ugyanaz történik. Részletesebben leírva, a geometriára vonatkozó árnyalási fázisok után egy jelenet hierarchiáját generáló részegység készít egy BVH gyorsítóstruktúrát. Ennek egy része statikus, vagyis újrahasznosítható, de az animációk miatt szükség van dinamikus, azaz jelenetenként frissülő adatokra is. Tulajdonképpen ez az alap, az egész működés kiindulási pontja, ugyanis eléggé fontos, hogy a hardver az egyes sugarak tesztelésekor ne menjen végig az összes jelenetben található háromszögön, mivel az eléggé lassú lenne. Ezeket inkább csúnyán fogalmazva bedobozolja, és a sugárnál így elég azt tesztelni, hogy eltalálja-e az adott dobozt. Valamelyiket el fogja, és ilyenkor elég csak azokra a háromszögekre koncentrálni, amelyek az adott dobozon belül vannak. Persze részletes geometria mellett nem árt többszintű struktúrát alkalmazni, ami – ismét csúnyán fogalmazva – dobozokat jelent majd a dobozban. A végeredmény szempontjából az a lényeg, hogy kellően mély legyen az adott BVH gyorsítóstruktúra, aminek hála ugyan hat-hét dobozon talán át kellett menni, de végül csupán pár vagy pár tucat háromszögre kell csak tesztelni az adott sugarat. Ez pedig még mindig gyorsabb, mintha erőből csinálnánk mindent.
A Coreteks elmondása alapján a traversal coprocessor magát a metszést vizsgálná, vagyis azt, hogy mikor talál el végre egy háromszöget egy sugár. Ilyen formában az történne a hardveren belül, hogy maga a grafikus vezérlő létrehozná a meglévő adatokból a gyorsítóstruktúrát. Annak dinamikusan változó részeit jelenetenként átmásolná a traversal coprocessor memóriájába, ahol természetesen a statikus adatok is ott lennének, ezeket elég ugye egyszer elhelyezni, hiszen nem frissülnek. Az adatmásolás természetesen időbe kerül, és maga az adatmennyiség is kellemetlen lehet egy kifejezetten mély BVH gyorsítóstruktúrák alkalmazásakor, de nem ez a legfőbb probléma a koncepcióval, hanem a sugarak követése. Amikor ugyanis végre találna a traversal coprocessor egy olyan háromszöget, amelyet metsz az adott sugár, akkor az adatokat begyűjtve lehetne visszazakatolni az összeköttetést biztosító buszon a grafikus vezérlőbe, hogy le lehessen futtatni a feldolgozókon az úgynevezett hit shadert. Még ez se lenne olyan hatalmas baj, de egy sugár útja itt nem ér véget. A háromszögről ugyanis vissza fog verődni, és ezt is ki kell számolnia a grafikus vezérlőnek. Gond egy szál se, részben erre való a hit shader, de a keletkező adattal máris lehet visszamenni a traversal coprocessorba, ahol ismét kezdődik a munka a dobozokkal, majd jön az újabb találat. Nagyszerű! Irány is a grafikus vezérlő, újabb hit shader, újabb adatok, vissza a traversal coprocessorba, ahol jön újra a dobozos meló, és ezt egészen addig kell folytatni, amíg lesz metszéspont. Ez pedig attól függ, hogy egy adott sugár mennyire hosszan lesz számolva a virtuális térben, de egyszer azt fogja mondani rá a rendszer, hogy nincs több metszés, és akkor be is fejeződik az ide-oda rohangálás, a grafikus vezérlő pedig lefuttathatja az úgynevezett miss shadert.
A fentiekből látszik, hogy egyetlen egy sugár is képes lenne rendesen túráztatni azt a buszt, amellyel ez az ominózus traversal coprocessor rá lenne kötve a grafikus vezérlőre. Egy képkocka számítása során akár négyszer-ötször is kellene ide-oda másolgatni az adatokat, ami finoman szólva sem szerencsés a busz késleltetését beleszámolva – sugaranként persze. Talán ezért sem láttunk még olyan rendszert, ahol egy külső lapka csinálta volna meg a bejárási lépcsőt? Talán a mérnökök észben tartják ezt a problémát? Valószínűleg a gyártók minimum figyelembe veszik, ők erről azért tudhatnak, a YouTube videósok viszont nem. De ebben a csodálatos világban mégis a YouTube videósok elemzése fut át a médián, nem is foglalkozva azzal a kérdéssel, hogy egy különálló lapka milyen problémákat hoz be az egyenletbe, pláne egy olyan bonyolult eljárásnál, mint a sugárkövetés. Minek is ezzel foglalkozni, a szenzációt már megadta maga az alapanyag, jelen esetben a traversal coprocessor, szegény olvasót ne zaklassuk már olyan jelentéktelen dolgokkal, hogy egyáltalán működhet-e.
Az egésznek egyébként valószínűleg van egy olyan háttere, hogy a gyártók egyre többet beszélnek a chiplet dizájnokról. Ezzel önmagában nincs semmi baj, mert megvannak a maga előnyei. De attól, hogy egy problémát meg lehet oldani chiplettel, még nem biztos, hogy ez mindenre jó. A gyártók sem fognak úgy dolgozni, hogy ész nélkül chipletet raknak mindenhova, hanem csak akkor vetik be, ha annak előnye van a hagyományos, monolitikus tervezéssel szemben. A központi processzoroknál például előnye van, de a grafikus vezérlőknél már kétséges, hogy az egyes részegységek, fő lapkából való kiszakítása hasznot hoz, ez már csak azért is egy problémás terület, mert nagyon másképp működnek ezek az adatpárhuzamosságra tervezett rendszerek. Minden bizonnyal lesz majd valamiféle megoldás a GPU-k esetében is a chipletre, de egészen biztos, hogy nem a fixfunkciós egységek kihelyezése a kulcs.
