16 690
Tesztek Android Google Apple Microsoft Samsung Huawei Linux Okostelefon Biztonság Tudomány Facebook Videojáték Film
16 690

CPU‑limit fejtágító

2009.11.18. 21.23
Netszerte gyakran hallani olyan kérdéseket, hogy az XYZ grafikus kártyát KIHALYTYAE az xyz2 processzor x ghz-en. Beletéve a processzort egy bojtár zsebébe, a videókártyákat meg a birkák oldalára kötni, és megnézve reggelente, bizony úgy tűnhet, kihalytya őket a legelőre. Tehát végülis a kérdés értelmes is lehet bizonyos elvont szempontokból nézve, ha elég sok tudatmódosító szert szed a delikvens. Én most, mint fejlesztő, el fogom magyarázni a CPU-limit, és egyéb limitek mibenlétét, ami a számítógépes játékokban jelentkezhet. Józan, paraszti ésszel felfogható módon, áltudományos hablaty nélkül.

CPU limit:


CPU limit akkor keletkezik, amikor egy játék túlságosan igényli a processzor számításait a tartalom megjelenítésére, és a grafikus kártya sebességéhez viszonyítva túlságosan is lassan számolja ki a tartalmat. Hogy egy példát mondjak, a stratégiai játékok nagy része CPU limites, ugyanis a rengeteg egység AI-ját kiszámítgani eléggé bonyolult folyamat. Hiába bírná a videókártya akár 400 fps-el is tekerni az igencsak egyszerűen megformált scenet, ha a mesterséges inteligencia egyszerűen nem tud 0,03 sec alatt végezni, a játékot ezáltal 33 fpsre kárhoztatva. Persze ez nem zavaró, ha cserébe mondjuk 20.000 egységgel onthatod a vért valós időben. Ennek a csúnyább változata az, amikor egy teljesen hétköznapi játék lesz cpu limites, csak azért, mert a készítők egyszerűen nem bírták normálisan megírni a játék egyetlen részét sem, és egyszerűen egy 1 ghz fölötti gép nem bírja játszhatóan mozgatni az összecsapott kódot. Ezt általában a túlzott objektumorientáltság, a mezei paraszti ész teljes hiánya, és az utólagos optimizálás hiányának együttesei okozzák. Ha már egyszer így megírták a játékot, utána már nagyon nehéz optimizálni a sebességen, a rossz alapoknak köszönhetően. A fejlesztők egy ilyen malőr után általában azzal a kifogással jönnek, hogy kevés volt az idő, meg bla bla bla. A dolgot viszont el lehetett volna azzal kerülni, hogy a fejlesztő a segge alá nem a legújabb 4 magos csúcs corei7 processzorokat rakja, hanem valami korai 1,7 ghz-s, 1 magos A64 processzort.

Tehát a nyers CPU limitnek 2 alfajtáját különböztethetjük meg:

1. A játék jellegéből is műfajából adódó sajátos cpu limitet (pl az AI miatti a stratégiai játékokban)

2. A programozók trehányságából vagy hozzá nem értéséből adódó rosszul felépített kódok okozta cpu limitet

A mai AAA játékok sajnos már hosszú évek óta a másodiktól szenvednek (olyan 2003 óta), 1-2 éve pedig már a garázsprojektek, scenedemók, egyszerű gamek is gyakran esnek ebbe a hibába, pedig ezen játékoknak inkább a régebbi gépekre (is) kellene készülniük a szűkösebb lehetőségek miatt. A probléma megoldására a legjobb gyógyír az ésszerű fejlesztés. Ha a baj már megtörtént, az utólagos, véres optimizáció nyújthat segítséget a károk enyhítésében. Pár általános jellegű tippet azért adhatok, de itt elsősorban logikai és vázlatbeli eltéréseket kellene inkább sorolnom, de azt konkrét cél nélkül nehéz lenne.

-Az objektumorientált programozás bizonyos programozók számára kényelmes (és a használói felsőbbrendű lényeknek tartják magukat, míg mások hánynak és köpnek tőle), ám a sebességkritikus részeken ne használj OOP kódot. Nem kell róla lemondani, de ha egy sebességkritikus helyen a cica->kutya->GetMeresiHiba(NULL, NULL) sort hívogatjuk, akkor inkább tedd az értékét egy lokális változóba, pl float tmpcickutymeres=cica->kutya->GetMeresiHiba(NULL, NULL);, és ezt a változót használd a továbbiakban. Ne bízz abban, hogy a compiler ezt meg fogja helyetted csinálni. Egy 5 kbyteos forrásban meg fogja. Egy 500 kbyteosban nem fogja.

-Ne futtass hosszú tömbökön többször ciklusokat végig, lehetőleg mindig mindent egy menetben végezz el, amíg az értékek a cacheben vannak, mert a memória elérése lassú és nehézkes. Inkább hajts végre több műveletet a ciklusmagban, minthogy mégegyszer végignyálazd a tömböt. Akár 2x-es sebességet is nyerhetsz.

-A vertexeket lehetőleg mindig olyan sorrendben olvasgasd ki, és pakolgasd, mind amilyenben a memóriában vannak. Ne ugrálj a memóriában és a programkódban.

-Kerüld a floatokkal való összehasonlító műveleteket, pl fcmp. Ilyen lehet pl a float a=..,b=..; if(a>b){...;}; kódrészlet. A lebegőpontos számok összehasonlítása 20 órajel. Az integereket floattá, és a floatokat integerekké való konvertálástól is óvakodj, az is brutálisan lassú. A kritikus helyeken inkább tárold el jó előre az értéket egy integer és egy float változóban is, és annak alapján hasonlítgass.

-A beépített c függvények (pl sprintf, atoi, atof) brutálisan lassúak. Kerüld őket, vagy írd meg egy részüket (csak annyira, amennyire használod őket) saját magad, és a sebességkritikus részeken inkább azokat használd. Így 2-3x-es sebességelőnyre is szert tehetsz.

-A brutálisan nagy forráskód, a mindennel széttupírozott alapengine brutálisan lassú, mert a processzornak hatalmas kóddömegen kell keresztülverekednie magát, mire túljut az alapcikluson. De erről majd később fog egy konkrét pont foglalkozni.

VGA limit:


VGA limit akkor keletkezik, amikor a grafikus kártya brutális mennyiségű feladatot kap a cpuhoz képest a tartalom létrehozásában. Ez inkább ideálisabb állapot egy grafikus engineben, mint az, ha cpu limit van. Az a legjobb, ha egy játék nyersen VGA limites, és ugyanakkor szaggatásmentesen fut a szerényebb hardverekkel ellátott gépekkel is. Akkor jelentkezik kellemetlenül ez a limit, amikor egyre több és több effektet kezdünk a 3d-s scenere pakolni, pl bump mapping, real time árnyékok, motion blur, hdr. Előfordulhat az is, amikor csak a kártyának valamelyik részegységét sikerül túlterhelni, és a kártya többi része addig szúnyókál: pl részecskerendszerek. Ekkor a TMU-k, mint a güzü, majdnem kiszakadnak a kártyából, úgy szenvednek, a videókártya többi része (pl. psh, vsh, transzformációs egységek) épp a Bahama-szigeteki nyaralásukat töltik. A mai és a régebbi videókártyák felépítésének arányai is mások. Míg az ezredforduló előtt egy pixelfutószalagra jutott átlagban két textúrázó egység, az ezredforduló utánra ez 1:1 arányra módosult, és később megjelentek a pixel és vertex shaderek.



Pixel
Pipeline

Textúrázó
egységek

minden pixel
pipelinehez
külön-külön
(TMU)

Pixel
shaderek

Vertex
shaderek

Egyszerre
ennyi pixelt
tud kiszámolni


(ha nincs
multitextúrázás)

Egyszerre
ennyi pixelt
tud kiszámolni


(ha multitextúrázás
is van)

Voodoo 1

1

1

1

1

Voodoo 2

1

2

1

2

GeForce 2 MX

2

2

2

2

GeForce 4Ti

4

2

4

elfelejtettem

4

Radeon 9800

8

1

8

2

8

8

RadeonX1650

8

1

48

8

8

8

Radeon HD 5970

sok

1

3600

sok

sok


Táblázat: videókártya generációk felépítésének arányai





A pixel shaderek kezdetben 1:1 arányban voltak a pixel futószalagok fejlődésével. Mára egy nagyságrenddel több shader egység kerül a grafikus kártyákba, mint pixel futószalag, illetve a hagyományos pipeline szerkezet eltűnt, a fixedpipe funkciók nagy részét shaderek emulálják. Ez azt jelenti, hogy tulajdonképpen a régi effektek nem gyorsulnak olyan ütemben, mint amilyen ütemben a shaderek, vagy éppen a memória hozzáférés a vga-n. Elkerülve ezt, igyekezzen mindenki a kódjában a lehető legfinomabb beállítási lehetőségeket elhelyezni, amelyekhez aztán profilozni lehet a különböző gyártók és korok konstrukcióit felépítés és teljesítmény alapján. Egy tipikusan VGA limites játék pl a furmark. Bár az nem is játék.

A VGA-n lehet még limites a vertexek feldolgozásának a sebessége is a GPU-n belül, illetve a videómemória sávszélességének alacsonysága is kellemetlen lehet a posztprocesszállt effektek esetén. Éppen ezért javasolt a posztprocesszálást kikapcsolhatóvá tenni, mert a régebbi videókártyáknak nagy érvágást fog jelenteni a futtatásuk. A VGA limithez viszont még hozzátartoznak nagyon fontos jelenségek, amelyeket külön pontban fogok részletezni:

Videó-memória méret-limit:

Ha pl túlságosan sok textúrát szeretne az ember megjeleníteni, a videókártyán lévő grafikus memória el fog fogyni, és az el nem férő textúrákat a driver a rendszermemóriában fogja tárolni. Viszont amikor geometriát szeretne a grafikus processzor ezekkel a textúrákkal kirajzolni, a textúrákat vissza kell tölteni a grafikus memóriába. (Az AGP és PCI-E sínrendszerrel majd a következő pontban foglalkozom.) A lassulás (ami 300 fpsből csinálhat akár 10-et is) kiküszöbölésének egyik legjobb formája a textúra-tömörítés használata. A tömörített textúrák minimális minőségromláson átesve méretük 1/6 részére zsugorodnak (persze itt nem a felbontásukra kell gondolni, nem az zsugorodik, hanem a hely, amit a memóriában elfoglalnak) majd kirajzoláskor a grafikus processzor hardveresen, on-the-fly tömörítheti ki a textúrákat. Ez remekül hangzik, ám amikor kevesebb textúra van a videómemóriában, mint a videómemória mérete, a textúratömörítés lassít a renderelés sebességén. Érdemes tehát a textúratömörítést bekapcsolhatóvá tenni, annál is inkább, mivel egyetlen paraméter átírásával hozzáadhatjuk az enginehez ezt a remek technológiát. A textúratömörítést először az S3 találta ki, S3TC néven futott. Az S3TC-t a mai videókártyák nagy része is támogatni szokta, de javasolt inkább a generikusabb textúratömörítési változatokat használni (pl dxtc, GL_ARB_texture_compression). Tulajdonképpen OpenGL alatt mindkettőt érdemes, ha az egyik nincs, talán még ott van a másik.

AGP limit:

Ezt a témát a fentebbi részekben úgy kerülgettem, mint macska a forró kását. A legtöbb fejlesztő erről nem beszél, mert vagy nincs tisztában vele (sőt, a legtöbb fejlesztő olyan fogalmakkal sincs tisztában, hogy FSB. Persze ők szoftveres arcok, de sokkal hatékonyabban fejleszthetnének pontosabb hardverismeretek birtokában), vagy pedig egyszerűen elsiklanak felette. Régebben (96-97) a grafikus kártyák PCI sínen keresztül csatlakoztak a rendszerhez. A PCI sín sebessége 33 mhz. Ez egy 32 bites csatlakozófelület, ami azt jelenti, hogy elméletileg a PCI sínen keresztül maximum 133 mbyte adatot lehetne mozgatni másodpercenként. A gyakorlatban ennek sajnos csak töredéke mozgatható, továbbá a PCI sebessége megoszlik a többi hardver között (pl hangkártya, hálózati kártya). PCI sínen keresztül így maximum 20.000 polygon küldhető ki játszhatóan a képernyőre. Kezdetben ez nem is volt, lévén hogy ennyi polygont a grafikus kártyák amúgyse bírtak volna kiszámolni, később viszont szűkössé vált, és megjelent az AGP. Majd lett AGP 2x, 4x és 8x. Az AGP 2x elméletileg 533 mbyte/sec, az AGP 4x 1 gbyte/sec, a 8x pedig 2 gbyte/sec átviteli sebességet biztosít papíron. Gyakorlatilag ebbe számos egyéb tényező is beleszól, ilyen például a rendszermemória sebessége (amit a korabeli alaplapokon még csak nem is lehet ilyen sebességgel írni). Háromszög alapú geometriával, háromszögenként (3(csúcspontok)*(3(xyz)*4(float) + 3(normalok)*4(float) + 2(uv)*4(float))) tehát 96 bájtnyi adatot kell elküldeni a videókártyának. Meg persze adatokat arról, hogy most épp vertexeket, uv-t, normalokat küldessz -e, és egyéb vezérparamétereket. AGP-2x-el olyan 32.000, AGP 4x-el 40.000, AGP-8x-el pedig 70.000 polygon küldhető ki játszhatóan a grafikus kártya felé. Persze ez így brutálisan kevés lenne egy mai több millió polyt használó játékhoz, így aztán olyan GeForce2 körül bevezették a VBO-t. Ennek a lényege, hogy a sokszögeket is a grafikus kártya memóriájában tároljuk, és ez teljesen hardveres triangle setupot követelt. Sok videókártya ki is halt ekkoriban. De most mellőzzük kicsit a dínók egyedfejlődését, térjünk vissza arra a problémára, hogy adatot akarunk AGP-n küldeni. Ezt akkor tesszük, ha valami változik a sceneben (pl egy modell sétálgat, mert animált). A legeffektívebb eredményt úgy érhetjük el, hogy:

-A nem látható geometriát eleve ki sem küldjük a grafikus adapternek.

-A látható geometria hátoldalát (normál alapú cullozás) már eleve nem küldjük el a grafikus adapternek.

Ezeket nem érdemes a driverekre bízni. Nem fogja normálisan megcsinálni se egy ezer éves, se egy 2 hetes videókártya. Szépen ki kell számolgatni, hogy mi látszik, és mi nem. Az újabb videókártyák számára a dinamikus sokszögeket glvertex3f helyett érdemesebb inkább arrayként elküldeni, így kicsit kevesebb lesz az AGP terheltsége (akár fele/harmad akkora!), és nem hívogatsz függvényeket sem lépten nyomon, ami a procidnak tesz jót. Természetesen ez mind PCI-E-re is vonatkozik. Az újabb kártyákon akár geometry shaderek vagy vertex shaderek segítségével is meg lehet írni az animációt, így a geometria végig VBOsítva maradhat, kihagyva a játékból az AGP-t.

Engine alap-FPS

Az engine alapfps a fent említett limitek összességéből adódik. Minnél komplexebb a game engine, annál kevesebb lesz az alap fps. Az alap fps értékek általában titkosak, mert eléggé kényesek rá a programozók. A megadásához általában a konfigurációt, és a használt ficsőröket sorolják fel, majd az enginet üresjáratban elindítják, és lemérik az fps-t.

Példa: 1 ghz P3 + GeForce4 Ti4200, 300 fps

Amennyiben az engine nagyon primitív és egyszerű (tehát csak grafikai engineből áll) és nem 4 számjegyű az alap fps (mai középkat gépre tessék gondolni), ott bizony nagyon csúnyán elrontottak a programozók valamit. Pl egy OpenGL-es tutorial, amely egy háromszöget kirajzol, mindenképpen 1000 fps fölött fog futni egy mai jó számítógépen. Amennyiben ez nem így van, konfigurációs problémák merülhetnek fel - vagy a programozó hibázott. Manapság egy komplex enginevel is illik átlépni az 500 fps-es határt egy középkategóriás géppel (postprocess nélkül). Az ezredforduló előtt egy 150 alap-fps-el futó engine már nagyon jónak számított. A legjobb persze manapság is az, ha az alapfps 4 számjegyű, de ez csak egyszerű enginek esetén fog bekövetkezni, egy több megás forráskóddal ellátott game engine egy bizonyos forráskód méret fölött drasztikus mélyrepülésekbe fog kezdeni. De ez nem baj, ha a megadott kb 500 fps-es érték felett marad. Egy Core i7-es gépen olyan 1200 fps a minimálisan elvárható alap-fps érték egy komplexebb enginetől is.

CPU limit (DRIVER):

Általában
a KIHALYTYAE kérdés esetén erre szoktak rákérdezni a turbópistik, csak
a válasz, amit kapnak rá, sajnos nem igaz. A grafikus kártya és
driverei által okozott cpu limitek egy bizonyos órajel felett
gyakorlatilag elenyésznek, egy bizonyos cpu órajel alatt viszont az
órajel csökkenésével szinte lineális esést produkálnak a 3d-s
teljesítményben. A grafikus kártyák drivereit általában az éppen aktuális hardvergenerációkhoz igazítják, de természetesen a driverek a sokkal régebbi processzorokkal is gond nélkül együttműködnek. Ezeket az értékeket most ünnepélyesen elnevezem ,,Geri féle fejlesztői KIHALYTYAE'' értékeknek (ohh istenem, az a szárnyaló egó :D) és a tapasztalataim alapján leírom, hogy VALÓJÁBAN milyen processzor kell egy adott videókártya kihajtásához. Az ezeken felüli gépigény már sajnos nem a driver limitjéből, hanem egyéb cpu limitekből származik.


Videókártya

Processzor

Voodoo 1AMD K5 133 mhz
Cyrix 150 mhz
Intel Pentium 166 mhz
Voodoo 2AMD K6 200 mhz
Cyrix 200 mhz
Intel Pentium 200 mhz
Intel Celeron 433 mhz
Voodoo 3300 Mhz CPU
GeForce 2Intel Pentium 3 600 mhz
AMD K7 550 mhz
VIA 850 Mhz
Intel Celeron 900 mhz
GeForce 4 TiIntel Pentium 3 700 mhz
AMD K7 650 mhz
GeForce FX800 Mhz
ATi Rage 128Intel Pentium 3 500 mhz
Radeon 7xxxIntel Pentium 3 600 mhz
AMD K7 550 mhz
Radeon 8xxxIntel Pentium 3 700 mhz
AMD K7 650 mhz
Radeon 9xxx1 ghz-s AMD/Intel CPU
GeForce 6xxx1 ghz-s AMD/Intel CPU
Radeon x1xxx1 ghz-s AMD/Intel CPU
GeForce 7xxx1,3 ghz-s AMD/ 1,7 ghz Intel CPU
Radeon HD2xxx1,3 ghz-s AMD/ 1,7 ghz Intel CPU
Radeon HD3xxx1,3 ghz-s AMD/ 1,7 ghz Intel CPU
GeForce 9xxx1,3 ghz-s AMD/ 1,7 ghz Intel CPU
GeForce GT2xx1,3 ghz-s AMD/ 1,7 ghz Intel CPU
Radeon HD4xxx1,3 ghz-s AMD/ 1,7 ghz Intel CPU


táblázat: fejlesztői KIHALYTYAE




Üdv, Geri


Kattints ide  ➜

Az Androbit technológiai és tudományos magazinnál hiszünk abban, hogy az információ mindenkit megillet. Hosszú évek munkájával megszerzett hírnevünknek köszönhetően megadatott számunkra az a lehetőség, hogy műszaki témájú médiumként is elérhessünk minden internetező korosztályt. Tesszük ezt olyan hírekkel és cikkekkel, amik között egyaránt szerepel nagyobb tömegeket és kisebb szakmai csoportokat érintő tartalom is.

A témák gondos összeválogatásának és a cikkek minőségi kidolgozottságának hála mára Magyarország egyik legnépszerűbb technológiai és tudományos információforrásává váltunk – fejlesztéseinkkel és kutatásainkkal pedig igyekszünk mindig egy lépéssel a versenytársak előtt járni.

A weboldalunkon található, szerkesztőségünk által készített tartalmakra vonatkozó összes felhasználási jogot az Androbit technológiai és tudományos magazin birtokolja. A tartalmak egyes részleteinek felhasználását kizárólag látványos (vagy jól hallható) forrásmegjelöléssel engedélyezzük. A feltételek megszegésének jogi következményei lehetnek. A feltételektől eltérő tartalomfelhasználás kizárólag megegyezés útján lehetséges.
Copyright © 2007-2016 – Makay József (makay@androbit.net)
A nap videója: Ez a különbség a vírus és a baktérium között
Telltale játék lesz a Guardians of the Galaxy
A következő Apple Watch okosóra már kör alakú lehet
Hamarosan Apple‑drónok fognak repkedni a fejünk felett
5700 darab iPhone‑t lopott el a Foxconn menedzsere
Gooligan és AirDroid ‑ Sok millió Android van veszélyben
Felkapott témák
Ezek a különbségek az iPhone- és Android-felhasználók között
Ezek a jelenleg kapható legerősebb okostelefonok
Az egyik legnépszerűbb antivírus egyben a legrosszabb is
Ezek a Huawei-készülékek kapják meg az Android 7.0 Nougat frissítést
Ingyenes nCore regisztráció - Újabb csalók próbálkoznak
A Firefox 0-day sebezhetőségével leplezik le a Tor-felhasználókat
Állásajánlatok
ICT Architekt PJ-7287
IT tanácsadó – Adózási Szolgáltatások területen
Méréstechnikai szakember
Architect Senior Budapest
Üzleti intelligencia munkatárs Budaörs
Vizsgáló mérnök
Senior JavaScript Developer