Új hozzászólás Aktív témák
-
namaste
tag
A háromszögek feldolgozása, a raszterizálás, a tesszeláció bizonyos részei, a TEX-ek, a ROP-ok hardveres egységek. Az a lényeg, ha valamely korlátozott számban rendelkezésre álló hardveres részt túlterheled, akkor hiába van rengeteg shader processzorod, azok csak várakozni fognak, romlik a kihasználtságuk.
A tesszeláció használatakor romlik a raszterizálás hatékonysága és a shader processzorok kihasználtsága is. Ha kivágod a nem látszó háromszögeket, akkor kevesebb marad és kevesebbet kell kirajzolni.
Ha CPU-n fut a nem látszó háromszögek kivágása, akkor sincs oda-vissza másolás, amit egyszer elküldtek a GPU-nak, az ott is marad. A tesszelálás során keletkező új háromszögeket sem küldik vissza a CPU-nak. -
-
azbest
félisten
nem hardveres vagy szoftveres közt van kérdés. Ma már nem jellemző, hogy fix funkciós egységek legyenek.
Az nem mindegy, hogy a gpu vagy a cpu csinál valamit.A különböző egymástól függő műveletek esetén nagyon nem mindegy, hogy oda vissza kell-e utazni adatoknak a cpu és gpu között vagy pedig maga a gpu tudja kezelni a problémát helyben. Nem véletlen, hogy a tesszelált grafikában van komolyabb különbség, mert ott a háromszögek elhelyeszkedése a gpu-n derül ki. Ha ott helyben lehet vágni is, akkor nem kell közben plusz kört futni a cpu felé, nem terheli azt is és várakozni sem kell rá.
Egy apu esetén persze a cpu is eléri a gpu memóriát, de a dedikált kártyáknál ez nem teljesen így van.
-
R-O-B-I
csendes tag
Nem, ezek az adatok CPU vágások nélkül vannak. Az Exclusively Culled azt jelenti, hogy a teljes jelenethez viszonyítva mennyi háromszöget lehet eldobni az adott módszerrel, ha csak kizárólagosan azzal a módszerrel történik a vágás. Az Inclusively Culled pedig azt, hogy az előző kivágások után maradt háromszögekhez viszonyítva mennyit, ha azok is beleszámítódnak a műveletbe.
Ezért is van ez a sorrend (Orientation, Depth, Small, Frustum), mert az egyes módszerekkel egyre kevesebb háromszöget lehet eldobni, így jobb inkább a hatékonyabbal kezdeni, hogy utána már kevesebbet kelljen vizsgálni, mint fordított esetben.
A Base az, amikor nincs semmilyen Compute Shader-es vágás, csak az amit a hardware csinál a raszterizáláskor. -
namaste
tag
A kivágást végző compute shaderek a GPU-n a shader processzorokon futnak, viszont ábrázoláskor kevésbé terhelik a háromszög feldolgozó és a raszterizáló egységeket, valamint a pixel shaderek a shader processzorokat, a textúrázókat és a ROP egységeket.
Az egyik dián az "Exclusively Culled" esetén csak a GPU-n fut a kivágás, az "Inclusively Culled" esetén a CPU+GPU végzi a kivágást. A további két dián, ahol a mért idők szerepelnek, a "Base" esetén nem tudom van-e CPU-n futó kivágás.
-
R-O-B-I
csendes tag
Ez megint egy olyan feature ami kb. 10-20 éves örökségek miatt kell. A lényege, hogy GPU-n Compute Shader-rel sokkal gyorsabb kiszámolni a láthatóságokat mint CPU-n, ráadásul így közvetlenül a GPU-n olyan módon lehet gyorsabban kirajzoltatni a geometriákat, ami CPU-ról sokkal lassabban menne.
Nézzétek meg a slideokat ([link]), nem csak a backface cullingról van szó, hanem pl. arról is, hogy az objectek fel vannak darabolva kisebb részekre (klaszterekre) és ezekre is van láthatóság vizsgálat, meg a poligonokra is, és végül a láthatatlan dolgokat nem is rajzoltatják.
A render engineek általában nem foglalkoznak ilyen szinten a clippinggel, mert részben a hardware megcsinálja, vagy CPU-ról csak lassabb lenne, ugyanis eddig az API-k nem adtak rá gyors eszközt. Másrészt nincsenek mindenhol expert developerek és egyéb resourceok (értsd: pénz és idő), hogy ilyen szintű R&D-ket csak úgy bevállaljanak... -
namaste
tag
A mai hardverek raszterizálás előtt el tudják dönteni egy háromszögről, hogy felénk néz vagy nem, és a felesleges háromszögeket eldobják. Viszont ennél többet nem tudnak. Előfordul, hogy egy takarásban lévő háromszöget is raszterizál, minden pixelére lefut egy-egy pixel shader, azaz feleslegesen dolgozik.
A GeometryFX és Frostbite csapat munkája egy szoftveres eljárás, GPU-n futó compute shader(ek), ami eltávolítja a nem látható háromszögeket. Ennek első lépése a nem a felénk néző háromszögek eltávolítása. Azért ez az első, mert hatékony, átlagosan a háromszögek 50% eltávolítható és kicsi a költsége.
Ez az egész arról szól, hogy mikor jársz jobban:
- ha a hardverre bízod, ami nem távolít el minden takarásban lévő háromszöget ezért feleslegesen dolgozik,
vagy
- raszterizálás előtt szoftveresen eldobod a takarásban lévőket és csak azokat ábrázolod, amelyek tényleg látszanak.
Mérések szerint a második megoldás jobb. -
csongi
veterán
Nem értek ezen részéhez, ezért inkább csak böffentés lehet. De ez elszomorít, hogy most kerül bele valamilyen formában a motorba. Eddig miért nem?
Valóban nem egyszerű eldönteni, mi látható mi nem, melyik hardver mit számoljon. De akkor eddig milyen optimalizációkról is volt szó? Ha ekkora adat mennyiségeket kellett kiszámolni, csak azért, hogy eldönthető legyen, megjelenik vagy sem az adott képkockán.... Hát akkor inkább csak a porhintés volt? -
fpeter84
senior tag
Mivel Te írtad a cikket ezért feltételezem hogy valóban van mögötte újdonság is, nem csak egy marketing bullshit fordítás, de akkor ez most miben más mint a jó öreg hardveres T&L ami már ~17 éve alap? Az nem pontosan erre lett kitalálva, hogy tele lehet tolni a teret iszonyatos mennyiségű poligonnal, de a GPU le tudja válogatni és csak azzal foglalkozik ami látszik is belőle, továbbá képes a részéletes objektumokat kevesebb háromszögre visszabutítani ha távolabb vannak a nézőponttól?
Emlékeim szerint a GTA3 volt az egyik első játék ahol nagyon látványosan kiütközött, hogy bár régi játékokban nem volt brutális különbség egy jobbfajta TNT2 Pro/Ultra valamint egy GeForce256 között, de a gyakorlatban a T&L-mentes TNT2-n játszhatatlanul akadt a GTA hatalmas tere, a GeForce meg már elbánt vele a hw T&L-el...
-
#22
CptAdamica
veterán
Parano1d
#20
CptAdamica
veterán
-
nyunyu
félisten
lehet mellé lövök, de ha más gpu által végzett műveletek eredménye is befolyásolja, hogy mi lesz takarásban (tesszeláció például?), akkor azt cpu irányból nem biztos, hogy hatékony / hibamentes kezelni.
Alapvetoen nem a takarassal van bajom, mert az tenyleg problema.
Hanem a tesszelacio soran keletkezo haromszogekrol annyira egyszeru eldonteni, hogy a kamera fele nez (targy elolapja), vagy nem (hatlapja), hogy ha ezt eddig nem kezeltek a GPUs futoszalagban, azert nem egyszeru ejnye-bejnye jar.
Ezt ne akarjak bemeselni, hogy ez optimalizacio.
Vegulis 1+1-et ugy is ki lehet szamolni, hogy 1+1+1+1, aztan osztani kettovel, csak ugy feleslegesen tovabb tart a muvelet
-
nyunyu
félisten
Az csak a geometriára vonatkozott és ugye egy jelenetet messze nem csak a geometria kiszámolásából áll. 400+ ezer kirajzolandó háromszöget csökkentett az eljárás közel az 1/5-ére.
Ha jol ertelmezem ezt a kepet, akkor a 348k eldobott haromszogbol 204k olyan volt, ami a kepen lathato testek nem felenk nezo oldalat alkotta. (orientation sor)
Ezek eldobasa annyira trivialis, hogy ha ezt akarjak eladni, mint uj fejlesztes, azert jar a szoges f*szkorbacs.Takarasban levo haromszogek (depth sor, 90.2k), meg a kicsi haromszogek (small 37.6k) mar nehezebb dio, ugyanis azokrol elso ranezesre nem mondhato meg, hogy eldobandoak, hanem vegig kell szamolni a transzformaciokat, aztan ha mar minden kesz, csak utana lehet megmondani, hogy kell-e a haromszog, vagy sem.
Ezt szoktak hanyagolni, es ugy kerulik meg a problemat, hogy Z szerint rendezve hatulrol elore sorrendben rajzoljak ki a haromszogeket.
Igy ha egy pixel mogott 12 reteg van, akkor az a pixel 12x lesz ujrarajzolva...Igazabol az vagta ki a bullshit meteremet, hogy azt sugalljak, hogy 443.4k haromszogbol maradt 95.4k.
Ha levonom a trivialisan eldobando 204k-t, akkor az jon ki, hogy 239.4k haromszog helyett rajzolunk ki az optimalizacio utan 95.4k-t.
Nyilvan az is tobb, mint a semmi, de messze nem akkora javulas, mint aminek be probaljak allitani. -
nyunyu
félisten
Az csak a geometriára vonatkozott és ugye egy jelenetet messze nem csak a geometria kiszámolásából áll. 400+ ezer kirajzolandó háromszöget csökkentett az eljárás közel az 1/5-ére.
Ha jol ertelmezem ezt a kepet, akkor a 348k eldobott haromszogbol 204k olyan volt, ami a kepen lathato testek nem felenk nezo oldalat alkotta. (orientation sor)
Ezek eldobasa annyira trivialis, hogy ha ezt akarjak eladni, mint uj fejlesztes, azert jar a szoges f*szkorbacs.Takarasban levo haromszogek (depth sor, 90.2k), meg a kicsi haromszogek (small 37.6k) mar nehezebb dio, ugyanis azokrol elso ranezesre nem mondhato meg, hogy eldobandoak, hanem vegig kell szamolni a transzformaciokat, aztan ha mar minden kesz, csak utana lehet megmondani, hogy kell-e a haromszog, vagy sem.
Ezt szoktak hanyagolni, es ugy kerulik meg a problemat, hogy Z szerint rendezve hatulrol elore sorrendben rajzoljak ki a haromszogeket.
Igy ha egy pixel mogott 12 reteg van, akkor az a pixel 12x lesz ujrarajzolva... -
azbest
félisten
lehet mellé lövök, de ha más gpu által végzett műveletek eredménye is befolyásolja, hogy mi lesz takarásban (tesszeláció például?), akkor azt cpu irányból nem biztos, hogy hatékony / hibamentes kezelni. Kihozni a gpu-ból, cpu-val kezelni, majd visszatolni gpu-ba pedig nem hatékony.
-
nyunyu
félisten
-
rodrigez
senior tag
Az csak a geometriára vonatkozott és ugye egy jelenetet messze nem csak a geometria kiszámolásából áll. 400+ ezer kirajzolandó háromszöget csökkentett az eljárás közel az 1/5-ére. Ezen spórolt a rendszer, a többi dolgot utána ugyanúgy el kell még végezni. De ahogy látod tesszelláció nélkül is hozott a konyhára a 2 konzol esetében. A base értéket hasonlítsd össze a a szinkron és aszinkron móddal. Utóbbi kettő között nincs nagy különbség. De látszik, hogy tesszelláció alatt Xbox One-on vagy 80%-al csökket az idő. Bár azt nem tudom mire vonatkozik a ~11ms, majd Abu megmondja. Tán a teljes képkockára?
-
Cifu
félisten
Ez igen jól hangzik, de mennyi a mérhető hatása, vagy mikor lesz esélyünk, hogy ezt valóban ki is használják?
Mert az utolsó két ábrán csak azt látjuk, hogy a szinkron / aszinkron leképezés között mennyi a különbség. Korábban pedig az, hogy 22%-al kevesebb háromszöget kellett leképezni, feltételezem még nem azt jelenti, hogy akkor hirtelen 5x-ésre nő az FPS...
Emlékszem. hogy megdobta a GeForce 2-es eredményt 3DMark 2001 alatt. 
Új hozzászólás Aktív témák
- Latitude 5530 15.6" FHD IPS i5-1235U 16GB 256GB NVMe ujjlolv IR kam gar
- Apple Watch Ultra 3 - Titán Natúr / Titán Black 49 mm több szíjjal- bontatlan, 1 év Apple garancia
- Predator Helios Neo 16" QHD+ IPS i9-13900HX RTX 4060 16GB 1TB NVMe magyar vbill gar
- Apple Watch Ultra 3 - Titán Natúr / Titán Black 49 mm Milanaise - bontatlan, 1 év Apple garancia
- Nikon Nikkor AF-S 16-35mm f/4 VR ED Nano
- Dell és HP szerver HDD caddy keretek, adapterek. Több száz darab készleten, szállítás akár másnapra
- BESZÁMÍTÁS! Sony PlayStation 4 PRO 1TB fekete játékkonzol garanciával hibátlan működéssel
- Microsoft Surface Laptop 5 13,5" i7-1265U 16GB 512GB magyarbill 1 év garancia
- Bomba ár! Lenovo ThinkPad T480s - i5-8GEN I 8GB I 256GB I 14" FHD I HDMI I Cam I W11 I Gari!
- Telefon felvásárlás!! Apple iPhone 16, Apple iPhone 16e, Apple iPhone 16 Plus, Apple iPhone 16 Pro
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest