kvp#56
"Ennek akadálya most az, hogy a GF8xxx-es széria valamiért nagyon gyengén muzsikál ebben. Közben az ATI alaposan rágyúrt erre, de így egyelőre feleslegesen."
Nem olyan rossz a gf8xxx-as szeria, csak a akkor lassu, ha adat vagy feltetel vezerelt a ciklusszam. Ilyenkor a 16 alus (szalas) mag csak 1 szalon folytatja a vegrehajtast, tehat 16-odara lassul. Igy mar 128 helyett csak 8 szalon tud futni. Ez minden vliw architekturanak az atka, pl. ettol nem olyan jo az itanium uzleti logikaban. Tehat dinamikus elagazasoknal, ha azok nem linearizalhatoak ki, akkor 16-odara, ha linearizalhatoak akkor egymasbaagyazott if-enkent kb. felere csokken a teljesitmeny (1/8-adig ahol feladja a fordito a linearizalast). Az ati eseteben ezek a butetesek nem ervenyesulnek annyira, mert tobb darab de kevesebb alu-t iranyito mag van. Igy viszont az ati-k a nyers erovel vegezeheto vektorfeladatokban gyengek. (tehat shader model 1-2 hasznalata eseten)
Egyebkent a 32 bites lebegopontos teljesitmeny eddig is megvolt nvidia eseten is, csak az ati hasznalt 24 bitet, meg a dx9c idejeben. A szabvanyositasban mar rosszabbul allnak, ugyanis az nvidia fele negyzetgyok hiresen pontatlan, kb. 14 bites, a tobbi bit csak linearisan interpolalt. Ha tenyleg teljes lebegopontos precizitas kell, akkor az alu-kat ujra kell tervezniuk, de a fuggvenykezelo aramkoroket mindenkeppen.
A cube map array-k pedig kezelhetoek geometry partitioning-el, mar a voodoo2-re is voltak ilyen demok. Az egyetlen kulonbseg, hogy akkor meg a processzor vegezte el ezt a vertex valogatasi muveletet, mig most a shader kepes ra. Egyebkent a gf8800-as sorozat is tudja kezelni oket, csak lassabban es array elemenkent egy texture slot-ot fogyasztva, vagy shader-bol, de akkor 1 orajel helyett kb. 50-100 orajelet igenyelve. (ilyenkor shader-bol emulalja a texturazo egyseg szuroit) Ugyanez vonatkozik az uj szurokre, amiket kepes kezelni egy gf8800-as is, csak eppen sokkal lassabban. Viszont a bloom-ot eddig is ezzel a szoftveres trukkel rendereltek es cuda alatt lehetoseg van a teljesen szoftveres textura kezelesre is, linearis adattombokkent kezelve a memoriat. (mint a voodoo vagy wildcat kartyakon)
Mashol mar leirtam, de az igazan jo megoldas az altalanos processzorok bevezetese lenne. Ha a gpu magok altalanos skalar vliw processzorokkent mukodnenek (tehat 1 control unit, 1 aktiv szal alapon), akkor ki lehetne hagyni a jelenlegi texturakezelo es raster operation aramkoroket is, csak az alu-k szamat kellene kb. a duplajara novelni es minden szalnak sajat vezerloegyseget adni. Most egy gf8800-asban 8 vezerloegyseg van (8 magos), de 16 szalu a parhuzamositas (intel sse eseten ez csal 4). Mindez a jelenleg is meglevo altalanos linearis memoriainterface-el, eleg szep eredmenyeket adna es akar c++ kod is futhatna a gpu-kon kulonosebb optimalizacio nelkul. Az egyetlen problema a memoria elerese lenne, de ezt egy osztott L2 cache-el kezelni lehetne, mivel most kb. 1KB a lokalis memoria szalankent es 16KB magonkent. Ez kb. a regiszterternek felel meg. A cache hianya pedig a beepitett smt rendszerrel lett kikerulve, tehat amig a fo memoriat olvassa vagy irja egy szalcsoport addig egy masik fut. (dinamikus elagazasnal pl. a memoriamuveletek sem parhuzamosithatoak, tehat ilyenkor csak 1 szal kepes egyszerre memoria i/o-t vegezni, ami lassu) Az nvidia ezt a full crossbar memoriavezerlovel korrigalja, ami sokkal gyorsabb mint a ringbusz, viszont a jovoben nem igazan skalazhato.