- Nvidia GPU-k jövője - amit tudni vélünk
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- VR topik (Oculus Rift, stb.)
- A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
- Milyen billentyűzetet vegyek?
- 3D nyomtatás
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Milyen notebookot vegyek?
- Milyen TV-t vegyek?
- Vezetékes FÜLhallgatók
Hirdetés
-
Minden fejlesztőnek kipróbálható a Microsoft DirectSR API
ph A felskálázási eljárások támogatását egyszerűsítő rendszer a jövő lehetőségeire is gondolt.
-
No Man's Sky - Befutott az Adrift frissítés
gp Ahogy minden korábbi update, úgy a mostani újdonságok is természetesen ingyenesek.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
Új hozzászólás Aktív témák
-
nagyúr
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.
-
.mf
veterán
"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/
-
nyunyu
félisten
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?
-
flexxx2
őstag
Jó nagy a különbség a fury x és a konzolok között.
-
Abu85
HÁZIGAZDA
É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.
-
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?
-
nyunyu
félisten
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?
-
-
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.
[ Szerkesztve ]
-
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...Hello IT! Have you tried turning it off and on again?
-
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.Hello IT! Have you tried turning it off and on again?
-
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
Hello IT! Have you tried turning it off and on again?
-
Parano1d
aktív tag
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.
-
nakos1212
senior tag
Nem ezt hívják occlusion cullinganj? Az összes ENB-be van.
-
CptAdamica
veterán
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!
-
pomorski
őstag
Hát ez érdekes cikk volt. De vajon tényleg lesz érezhető hatása ennek?
-
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...
-
Dilikutya
félisten
É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.....)
-
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? -
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. -
R-O-B-I
újonc
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 ]
-
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
újonc
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. -
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.
[ Szerkesztve ]
-
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.
Új hozzászólás Aktív témák
- nVidia tulajok OFF topikja
- Nvidia GPU-k jövője - amit tudni vélünk
- A választási tévinformációk ellen küzd a Meta
- Diablo IV
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Politika
- Kerékpárosok, bringások ide!
- Casco és kötelező gépjármű felelősségbiztosítás
- VR topik (Oculus Rift, stb.)
- A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
- További aktív témák...
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen