Új hozzászólás Aktív témák
-
-
Abu85
HÁZIGAZDA
válasz
Pipapapi
#8111
üzenetére
Engem több fejlesztő úgy informált, hogy a többség élt a Physx licenszek ingyenes cseréjével. Ez azt jelenti, hogy a jövőben megjelenő physx-et használó játékok többsége már a Geforce féle megvalósítást is használja. Brothers in Arms H.H. az egy nagyon jó példa. Ebben a progiban a GF kari számolja a fizikát (már amelyik gépben ugye van ilyen kártya
) ... de ugyanakkor azt is megmutatja amit a cikkben írtam. Ez ebből a tesztből kiderül. A fejlesztők szerint is maximum +5%-ot hoz a GF karin a Physx. Egyszerűen nem komplex a fizika. Várhatóan a többi játékban sem lesz az, mert a konzolok nem bírnák. -
Abu85
HÁZIGAZDA
válasz
Pipapapi
#8106
üzenetére
Ez a Physx messze nem ilyen egyszerű téma ... szeptemberben erről a dologról rengeteg fejlesztőt megkérdeztem. Ebben a cikkben a "Fizika a játékokban" résznél leírtam mi a legfőbb problémájuk a programozóknak.
A Vantage-re meg tök felesleges alapozni ... a játék teljesítményt nem igazán tükrözi.
-
-
Abu85
HÁZIGAZDA
válasz
T.Peter
#2383
üzenetére
A raszterizálást leírom a Harmadik dimenzió első oldalának a renderelés pontjában.
A Radiosity a raszterizálásnak olyan kiterjesztése amikor a fényvektorokat nem csak a felület elérésig számolja a rendszer. Ugye a valós világban ugye nem csak a fényforrás bocsát ki fényt hanem azok a felületek is amire fény vetül. Ezt probálják a Radiosity-vel szimulálni.
A Ray-tracing az egy másik renderelő algoritmus. A működési elve elég bonyolult ... nagyon röviden és egyszerűen leírva, a pixelből merőlegesen kiindulva a fénysugarak útját követi vissza egészen a fényforrásig. Borzalmasan teljesítményigényes, de az elvei eléggé jól szimulálják a valóságot.
Egy kis példa a Ray-tracing és a Raszterizálás különbségének megértéséhez.o-||
1 || 2
0 || 0A kis ábra a te nézőpontodből egy a helyzetedhez merőleges falat reprezentál. Az a kis "o-" a fényforrás, a két "0" a tökür számokkal ellátva, hogy könnyebb legyen azonosítani őket a leírásban. Nagyon fontos, hogy a fal úgy áll, hogy a fényforrás a 2. tükörben nem látszik azaz a tükör árnyékban van, viszont a két tükör "látja" egymást.
Nézzük a raszterizálást. A kész képen látni fogjuk magát a fenyforrás fényét, és a tükörben is meglátjuk a fényforrást, mert úgy vetül rá a fényvektorok, hogy lássuk. A 2. tükör árnyékban van, ezért a fényforrás tökürképét nem látjuk, viszont a valóságban látni kellene az első tökürben megjelenő fényforrás tükörképét. A raszterizálásnak itt ütközünk a problémájába. A fényvektorokat csak a felület elérésig számolja a rendszer. Mivel a felület maga az 1. tükör, a 2. tükörben már nem fog felcsillanni a fény.
A Ray-tracing esetében a rendszer visszaköveti az összes olyan sugármenetet a pixeltől ami visszajut a fényforrásba. Ergo Ray-tracing esetében már a 2. tükörben is meglátható az 1. tükör segítségével a fényforrás.
Természetesen lehet trükközni is, hogy a raszterizálással is valósághoz hasonló képet kapjunk ... , de a lényeg, most a két technika eltérésének a bemutatásán volt.
A Voxel Space az hosszú lenne, nem hiszem, hogy fáradtan menni fog. Sry...
-
Abu85
HÁZIGAZDA
válasz
volvoguy
#2359
üzenetére
Az R600 alapjait az AMD a DX10-hez készítette. Az volt a cél, hogy létrehozzanak egy végtelenül rugalmasan alakítható rendszert ami nemhogy megfelel, de még felül is teljesíti a DX10. A DX11-hez is ezt az architektúrát fogják használni, mert úgy lett megtervezve, hogy könnyen integrálhatóak legyenek a DX11-es követelmények (sőt többségük már most is benne van az R600-ban). Abba gondolj bele, hogy a a DX10.1-et játszva beépítették az architektúrába, míg az nV nem tudja ezt megtenni, mert a GF8/9 architektúrája nem megfelelő a gazdasgos implementáláshoz. Ez röviden annyit jelent, hogy az nV-nek már a DX10.1 támogatáshoz is új architektúra kell.
A mai helyzetet az jellemzi, hogy az nV bevágta a durcit, mert a DX10-ben a Microsoft nem teljesen az ő elképzeléseit támogatta. Megjegyzem, hogy a Crysis sebességét látva, nem csodálkozok a Redmondiak döntésén... Az nV ezt szerintem úgy vette, hogy az MS nagyon az AMD technikáit pártolja (ez egyébként tényleg így van). Ettől kezdve elkezdte a fejlesztőket a saját elvei szerint igazgatni. Ez lényegében annyit jelent, hogy ha a fejlesztő nem adja be a derekát akkor vagy kilóra megveszik (Hellgate: London), vagy eltiporják az útból (Techland - Call Of Juarez). Mindkét játék fejlesztőinek az volt a bűne, hogy eszükbe jutott a DX10-es technikák alkalmazása (pl.: Geometry Shader, komolyabb Stream output használat). A Hellgate: London fejlesztőit sikerült meggyőzni, hogy az a legjobb a világnak, ha az AMD csoportját teljesen kizárják a fejlesztés és optimalizálás menetéből. A Techland nem adta be a derekát, mert ők pártatlanok akartak maradni, őket más úton intézték el (nagyon csúnya módon).
Gyakorlatilag az nV-nek a megítélés jelen pillanatban szinte mindegy. Olyan szinten függnek az Intel és az AMD akaratától, hogy ilyen piacon a vezető hely pillanatok alatt összeomolhat. Ezért nem jönnek új gyorsabb GF karik, mert a pénzt elkezdték átcsoportosítani más piacra. A VGA számukra hamarosan másodlagos szempont lesz.Az AMD egyébként az R600-zal nagyon sok dolgot ért el. Emlékszem 2006 körül azt mondta valaki az egyik előadásán, hogy 2009-re olyan gyorsak lesznek a GPU-k, hogy lehetőség lesz raszterizálás mellett valós idejű Global Illumination-ra, illetve Radiosity-re. 2007 közepén írt Emil Persson egy Global Illumination demót ami az R600-on 50FPS-sel futott. Cirka másfél évvel megelőzte az AMD a fenti kijelentést.
-
#2260
Abu85
HÁZIGAZDA
cowboy_bebop
#2255
Abu85
HÁZIGAZDA
válasz
cowboy_bebop
#2255
üzenetére
Csak év végére lesz képes a TSMC vagy az UMC 45nm-re (és ugye ők a legfejletebbek a gyártástechnológiában). Más gyártól nem nagyon lehet várok hasonló bravúrt, szóval nem hiszem, hogy a HD4000 már 45nm lesz.
-
Abu85
HÁZIGAZDA
Anti-Aliassing: Az Aliassing jelenséget próbálja minimálisan láthatóvá tenni. Többféle Anti-Aliassing megoldás létezik:
- Supersampling: Az Anti-aliassing legrégebbi, legegyszerűbb és legjobb képminőséget nyújtó megoldása. Minden egyes pixelt többször számol ki a videókártya, de az eredeti pixel pozícióhoz képpest mindig egy kicsit eltolva, majd összemossa a képet. Ezzel a módszerrel a legnagyobb a teljesítmény veszteség, nagymértékben fogyasztja a Fill Rate-et és a memória sávszélességet.
- Multisampling: Ez az eljárás azt vizsgálja, hogy a renderelt poligon mennyire fedi le az adott pixelt. Ehhez a pixelen belül mintavételezési pontokat helyez el, majd Z-tesztet hajt többször végre. Ez eljárás előnye, hogy nem fogyasztja a Fill-Rate-et mivel nem számítunk ki több pixelt csak amennyit az alkalmazott felbontás megkövetel, viszont az extra adatok a memória-sávszélességet továbbra is terhelik.
- Fragment: Csak a poligonok mentén lévő pixelességre fókuszál. Megvizsgálja, hogy a poligonok által a pixel fedve van-e, nincs fedve, vagy csak részben van fedve. Az első két esetben nincs semmi teendő, annál izgalmasabb viszont a harmadik, ahol a fedettség függvényében a pixeleket alpixelre (fragment-ekre) osztja fel, majd az alpixelek színeinek az átlagolásával határozza meg a végső pixelek színét. Sem a Fill-Rate-et, sem a memória sávszélességet nem terheli le, nagy hátránya, hogy csak a poligonok szelénél dolgozik (ez azért baj, mert a textúrákban lévő csíkokat nem veszi számításba), és Stencil buffer használta esetén nem alkalmazható.
- Edge Detect (képminőség javító eljárás): A poligonok mentén elhelyezkedő pixeleken történő szűrés esetén, a rendszer több mintát használ fel a számoláshoz.
- Temporal (képminőség javító eljárás): Ez egy régóta ismert élsimítási eljárás. A számítás az egymást követő pixeleken mindig más, véletlenszerű mintával történik. Kihasználja, hogy az emberi szem és az agy képes kiszűrni a véletlen zajt a képek értelmezésénél, így a monitoron leképzett képet szebbnek látjuk, mint amilyen valójában. A hátránya, hogy egy bizonyos képfrissítési érték alatt ronthat is a képminőségen.
- Gammakorrekció (képminőség javító eljárás): Szemünk érzékenysége és pontossága nagyban függ a fény erősségétől. A videokártyák az élek simításához lineáris színátmenetet használnak, ezt exponenciálisra alakítják és több értéket csoportosítanak abba a tartományba amelyre szemünk érzékeny. A képpont kiszámítás utolsó fázisában alkalmazható.
- Transparency/Adaptive (képminőség javító eljárás): Megvizsgálja a textúrát és annak alpha csatornáját, és a nem átlátszó területeken is élsímítást végez.
A Shader based AA lényegében megnövelt kompatibilítású MSAA eljárás, ennek segítségével a fejlesztők a grafikai motor képességeihez szabhatják az AA mintavételezést. Ezzel elkerülve a hibás megjelenítést.
-
Abu85
HÁZIGAZDA
válasz
Pietrosz
#2146
üzenetére
Sok helyen igen.
A Crysis a növények között átjövő napsugarakhoz Edge detect-et használ. Ha MSAA-val szűrsz akkor nem biztos, hogy az átszűrődő fény, nem a levél közepén fog áthatolni. Ezért amikor a Crysis-ban az AA élni fog a játék kikapcsolja az Edge Detect-et, illetve letiltja a Very High opciót a Shader beállításhoz (hogy ne legyenek hibás fénysugarak).
A Crysis-ra nem lehet driverből AA-t kényszeríteni, így speciel nem tudod az AMD Edge-detect algoritmusát ráerőltetni. Ennek az lesz az eredménye, hogy a növények levelei recésebbek lesznek, mint AA nélkül.
Az MSAA nem csak a Deferred Shading-gal nem kompatibilis, egy tucat olyan eljárás meleltt nem lehet használni ami ma már általános. Ezért hozták be a DX10.1-ben a szabványosított Pre-Defined mintákat, hogy a kompatibilítási problémákat megkerüljék. Nyilván itt keletkezett egy másik probléma, az SBAA szabványosan csak DX10.1-es karival működik, így meg lehet győzni a fejlesztőket az AA jelentéktelenségéről (Persze fontos szempont a pénz, mert ez az egyetlen dolog ami megváltoztatja a fejlesztők nézőpontját. Ritka az olyan "idióta" csapat mint Techland, aki többre tartja a technika fejlődését az nV pénzénél.). Átlag júzer meg úgy sem tudja, hogy mi mindent kapcsol ki a mai játékokban az AA bekapcsolásakor.
Grafkarira szabott SBAA algoritmussal, meg senki sem akar tökölni, mert a Stalker példája mutatja nem is olyen egyszerű ilyen algoritmust írni. Az új Patch-ben már van némi SBAA nV kariknál, de az eredmény 1FPS-lesz. Elvileg valaki rákényszerítette már Radeonokra, de ő sem kapott 5-6FPS-nél nagyobb sebességet. Tipikusan ez a baj a nem szabványos eljáráson alapuló SBAA-val, nagyon el lehet kúrni. -
Abu85
HÁZIGAZDA
válasz
theniel
#2094
üzenetére
Pedig a CF eléggé szoftverfüggő.
Annyi előnye van az SLI-hez képpest, hogy sokkal kellemesebb a hibák elhárítása. Ugye ha problémád van a játékkal akkor annyit kell tenni, hogy letiltod a Catalyst AI-t, az SLI-nél sajna újraindítás kell a deaktiváláshoz, illetve megpróbálhatod a driverben az SFR kényszerítést (de ritkán segít). -
Abu85
HÁZIGAZDA
válasz
theniel
#2088
üzenetére
COD4-ben igen, bár ott én főleg a Super AA miatt használom.
A Crysis-ben buherálni kell, de a Heldér Pinto móddal jó a CF skálázódás.A Stalkerban is jó lenne a CF, ha azzal a 60Hz-es force-al nem vibrálna a monitor. Így viszont nem tudom használni jól az AFR módot, mert a v-sync nincs maximalizálva. Így ki kell kapcsonom a Catalyst AI-t, mert bevillan néha a desktop.
-
#2089
Abu85
HÁZIGAZDA
Stalker-2572
#2087
Abu85
HÁZIGAZDA
válasz
Stalker-2572
#2087
üzenetére
[link] - nem éppen...
-
#2086
Abu85
HÁZIGAZDA
Stalker-2572
#2082
Abu85
HÁZIGAZDA
válasz
Stalker-2572
#2082
üzenetére
A fogyasztás két GPU-s rendszernél nagyon függ attól, hogy mi fut rajta és hogy használod a kari driverbeállításait. Nekem speciel CF rendszernél a Stalker alatt közel 60W-tal kisebb a teljesítményfelvétel, mint mondjuk a Call Of Juarez DX10 alatt. Egykártyával gyakorlatilag ugyan annyi kakaót zabálnak.
Speciel előfordulhat, hogy sikerült olyan helyen tesztelni a fogyasztást ahol az SLI nem igazán működött, teszem azt HL2.
Új hozzászólás Aktív témák
- ÓRIÁSI BOMBA AKCIÓK! PSN, STEAM, UBISOFT CONNECT, EA APP, XBOX EREDETI KULCSOK 100% GARANCIA
- BESZÁMÍTÁS! MSI B650 R7 7700 32GB DDR5 1TB SSD RTX 5070Ti 16GB LIAN LI LANCOOL 207 ADATA 850W
- Samsung Galaxy A33 5G / 6/128GB / Kártyafüggetlen / 12Hó Garancia
- Samsung Galaxy S23 128GB,Újszerű,Adatkabel,12 hónap garanciával
- Spigen Essential EF323MQ 3in1 Mágneses MagSafe Vezeték nélküli töltőállomás 25W Qi2.2 Fekete
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest