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...

Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

Lehet csak az áramszámlán látható a különbség, nem fűt annyira a kártya

"Nem látható elemek nem kiszámítása", helló ImgTech PowerVR TBDR, helló 2006...

Fotóim és kalandjaim a világ körül: https://www.facebook.com/fmartinphoto/

Hogy nem rugtak eddig p*cs*n a grafikus megjelenitomotor fejlesztoket?

Tetszoleges 15 evvel ezelotti szamitogepes grafika tankonyvben le van irva a culling menete...

Hello IT! Have you tried turning it off and on again?

És? Azok közül nulla vonatkozik a GPU által vezérelt futószalagokra. Itt nem a kivágásról van szó, hanem arról, hogy ezt nagyrészt végezze el a GPU és etesse saját magát.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Amit te keresel, az szerintem a base és total közti arányban van. A szinkron-aszinkron közt én se sok különbséget látok.

pezo77 #5 2017.12.14. 13:29 Hmm. És ez az e-hajó akkor hol is tud kikötni? Az e-bay -ben? ;)

nekem is dejavu erzesem van... ez nem 10-15 eve volt tema?

facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld

Nem, nekünk a felszín alatt hullámzó tengert kell számolni, meg mindent ami a hátunk mögött van.
Más is észrevette már, hogy a FOV növelése nem befolyásolja az FPSt?

3440x1400@120Hz #ultrawidemasterrace #gloriouspcgamingrace

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?

Csoda driver Nvidiánál? Emlékszem. hogy megdobta a GeForce 2-es eredményt 3DMark 2001 alatt.

Hát kb. így aránylik a 4096 számolóegység az 1152-höz és a 768-hoz.

Cikkbol elejebol nekem az jott le, hogy van egy evtizedek ota ismert problema, amivel eddig nem nagyon foglalkoztak.
Aztan most feltalaltak a spanyolviaszt...

Az, hogy a CPUn vagy a GPUn fut a nem megjelenitendo haromszogek eldobasa, az miben modositja a problemakort?

Hello IT! Have you tried turning it off and on again?

Foglalkoztak vele, csak nem elég hatékony.

A GPU-s módszer a problémát nem módosítja, csak máshogy kezeli. Jelen esetben úgy néz ki, hogy jóval hatékonyabban.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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.

[ Szerkesztve ]

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...

Hello IT! Have you tried turning it off and on again?

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.

Hello IT! Have you tried turning it off and on again?

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

Hello IT! Have you tried turning it off and on again?

Nem értem a sok negatív hozzászólást. A frostbite így is a leghatékonyabb motor PC-re/konzolra, ha a teljesítménye tovább javul, (tökmind1 hány százalékkal) akkor inkább kalapot kellene emelni, hogy megint letettek valamit az asztalra, ami jó a felhasználóknak.

Nem ezt hívják occlusion cullinganj? Az összes ENB-be van.

Szerintem is a legjobb motor a piacon és ezért lehet is dicsérni a frostbite csapatot, nem tétlenkednek, hanem fejlesztenek. Kíváncsi vagyok, hogy a Battlefront után milyen látványvilág vár ránk a Battlefield 5-ben, de valószínű kell majd egy kis sámli az államnak!

[ Szerkesztve ]

Megyen!

Hát ez érdekes cikk volt. De vajon tényleg lesz érezhető hatása ennek?

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...

És ez a legújabb Frostbite miben dolgozik?

Nem vagyok perverz, csak haladok a korral. (Még mindig: Rock&roll feeling baby, rock&roll feeling.....)

Sztem eddig is mukodott, csak most atraktak a gpu-ra... Aztan, hogy ez mennyit hoz a vs cpuhoz kepest, az kerdeses.

Atok

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?

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.

Dehát ahhoz, hogy szoftveresen meghatározható legyen mely háromszöget dobhatóak el, ahhoz hardveresen ugyan úgy számolni kell.
Vagy valamit félre értek?
Itt nem az a lényeg, hogy ki végezze el a feladatot? CPU vagy GPU?

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...

[ Szerkesztve ]

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.

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.

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.

[ Szerkesztve ]

Igazad van, ha összeadjuk az "Exclusively Culled" esetén a kivágott háromszögeket, akkor negatív számú megjelenítendő háromszög marad, ami fura lenne, tehát ezek az értékek külön-külön értendőek.
A sorrend világos, lásd #28 középső bekezdését.

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.