Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Csak a jegyzőkönyv miatt. A Crytek megoldása a GeForce RTX-en is gyorsabb, mint a DXR-es megoldás. Effektíve tehát nem az NV ellen dolgoznak, hanem pont ellenkező céljuk van, az NV hardveres megoldása ugyanis nem elég gyors számukra.
A lényeg itt az, hogy a sugárkövetés a háromszögeken nagyon rossz hatékonyságú, de a DirectX Raytracing nem támogat mást, tehát nem tudsz voxeleken dolgozni. A Crytek azt csinálja, hogy a sparse voxel octree total illumination technikához kidolgozott voxelizációs eljárás eredményét felhasználják, és a voxelizált jeleneten csinálják a bejárást. Ez sokkal hatékonyabb BHV bejárást eredményez, mintha háromszögeken dolgoznának, mert pusztán a gyorsítóstruktúra sokkal kedvezőbb kialakítású a voxeleken, sokkal kevesebb a felesleges munka, amire számolni kellene, de az eredménye kuka lesz.
A Crytek-féle megoldás a DXR limitációit teljesen kikerülő, és szoftveresen előállnak egy hatékonyabb megoldással, amire a DXR pusztán amiatt nem képes, mert a DirectX futószalagja sehogy sem kezeli a voxeleket. De ha kezelné is, akkor is kellene rá egy külön hardver. A Crytek ezt megoldja úgy, hogy a jelenetet a CPU-n voxelizálják. Utóbbi a kulcs, amit évekig fejlesztettek, de rengeteg dologra jó.
(#9) Predatorr: A DXR nem licencköteles megoldás.
Ez is teljesen szabványos. compute shadert használ, minimum shader model 5.0-val, tehát alapvetően egy shader model 5.0-s szabványot támogató hardver kell.
A Crytek is elvégzi a sugárkövetéssel járó számításokat, ezeknek a shadereknek a lefuttatása megkerülhetetlen a DXR-rel is, vagy bármilyen más megoldással. A CryEngine trükkje a bejárásból adódik, ami sokkal hatékonyabb, mint amit a DXR kötött formában felkínál. Hasonlóan trükkös megoldás amit a WoT felmutatott nemrég. Az is a bejárásnál dolgozik máshogy, csak az a CPU-n számol, de ettől az is ugyanúgy elvégzi a sugárkövetést shading részét a GPU-n, compute shaderekkel. A jelenlegi ötletek szempontjából tehát vannak fix pontok, amik mindenhol ugyanazok, a shading fázis például az, vagy a denoising is. A bejárásban vannak nézetkülönbségek, ugyanis sok fejlesztő szerint a DXR aktuális verziója rossz hatékonyságú, és emiatt születnek erre alternatívák, amelyek pont ezt a rossz hatékonyságot kezelik. De az RT többi lépcsője nagyjából ugyanaz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Nem. Semmi ilyet nem használ. Csak compute shadert. Azért nagyon gyors, mert nem a kötött BVH bejárással működik.
Azt egyébként nem zárták ki, hogy később hozzáadnak majd valami fixfunkciós gyorsítást, de egyelőre ez nincs tervben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az API és a meghajtó. Az AMD az erőforrásainak zömét a DirectX 12-re és a Vulkan API-ra rakja, és emiatt az ő DirectX 12 és Vulkan meghajtóik a leggyorsabbak. Emiatt van az, hogy kijön egy DirectX 12-es vagy Vulkan játék, és lényegében helyből működik. Ezzel szemben az NV még mindig a DirectX 11-re fókuszálja az erőforrásuk zömét, és a DirectX 12, illetve a Vulkan ezért kevesebb figyelmet kap. Emiatt van az, hogy a DirectX 11-es alkalmazásokban az NV gyorsabb tud lenni, de gondjaik vannak eleinte a DirectX 12-es és Vulkan játékokkal, amelyeket idő helyrehozni, lásd World War Z.
Az is lényeges, hogy a DirectX 11-es implementáció az NV-nél épp a legutóbbi driverekben javult sokat. Ez tett be mondjuk a GTA5-nek, de a lényeg, hogy gyorsabb lett. Az AMD már nem igazán raknak erőforrást a DirectX 11-be, így a korábban megért implementációt csak optimalizálják, de nem újítják fel jelentősen, ahogy az NV tette. Ezzel szemben nagyon sokat javítanak féléves szinten is a PAL-on, amiből csak a DirectX 12 és a Vulkan tud profitálni.
Végeredményben ez egy felfogásbeli kérdés. Az AMD szerint a DirectX 12 és a Vulkan a fontos, így abba rakják a pénzt és az erőforrást, hogy az érkező DirectX 12 és Vulkan játékok helyből jók legyenek. Az NV szerint még mindig a DirectX 11 a fontos, így ők inkább arra fókuszálnak, még ha annak az az ára, hogy nem minden DirectX 12 és Vulkan játék lesz azonnal jó.
Azt még hozzá kell tenni, hogy az AMD és az NVIDIA nagyon másképp csinálja a DirectX 12 és a Vulkan támogatását. Az AMD ezt alapvetően egy implementációból oldja meg. Van egy közös PAL, és fölé van rakva egy ICD, ami az API-ra vonatkozó adatokat tartalmazza. Tehát effektíve mindegy, hogy a játék DirectX 12 vagy Vulkan API-t használ, a driver oldalán ugyanazon a PAL rétegen fog futni. Az NVIDIA nem így csinálja, hanem van egy teljesen külön driver a DirectX 12-re és a Vulkan API-ra. Így mindkét API, a saját független implementációján működik. Mindkettőnek megvan az előnye és a hátránya. Az AMD megoldásának előnye, hogy roppant egyszerű, hiszen két API-t szolgálnak ki egy rétegből, vagyis elég ezt a réteget fejleszteni, és mindkét API-n javul a működés. Viszont maga a rétegezés miatt ennek teljesítményhátránya lehet ahhoz képest, mintha mindkét API-ra külön implementáció lenne. Itt van az alapvető nézetkülönbség, ugyanis az AMD szerint pusztán ott behozod ezt a sebességhátrányt, hogy egy rétegre dolgozol, függetlenül az API-k számától, míg az NV szerint hosszabb távon mindenképpen a független implementáció a nyerő.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez ugyanolyan szintű RT, ami van a DXR-es játékokban. A különbség az, hogy voxelizál, vagyis gyakorlatilag ugyanazt a számítást, nagyságrendekkel nagyobb hatékonysággal végzi, mint a DXR, ami sajnos rendkívül rossz hatékonyságú háromszögekre van kényszerülve. Ha mondjuk lenne a DXR-nek is voxelizációra megoldása, akkor az is ugyanilyen gyors lenne.
Effektet ugyanúgy rakhatsz ebbe is, mint a többi DXR-es programba. A kulcstényező a bejárás, amit már megcsinál a motor. Hogy annak eredményére építve milyen effekteket raksz még, gyakorlatilag mindegy. Abban igaza van a Cryteknek, hogy maga a visszaverődés az a problémakor, ahol az RT előnyösebb tud lenni a raszterizációnál, míg más területen a különbség szinte észrevehetetlen mondjuk egy voxel cone tracinges AO-hoz és GI-hoz képest (amit a CryEngine tud: SVOTI), miközben az erőforrásigénye az RT-nek sokkal nagyobb.
A CryEngine annyiban előnyben van, hogy sokan próbálkoztak az SVO-val. Epic, DICE, stb. Az NVIDIA-nak is volt ilyenje VXGI néven, csak nem mozoghatott semmi a jelenetben, mert megpusztult tőle. A Crytek az egyetlen cég, amely ezt a koncepciót úgy megoldotta, hogy működik is, nem csak tervezgették. Emiatt sokszor hasznosabb nekik erre építeni, míg mások ezt nem igazán tehetik meg, mert lyukra futott a kutatás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A cikket eleve update-elték, hogy túlpörgették a témát.
Az meg a másik, hogy ma real time szinten egyedül a Dreams, ami RT. Semmi más. Minden további játék raszterizációt használ és RT-vel csak effekteket számol. Ugyanez a CryEngine megoldása is, csak ők nem a nagyon lassú DXR bejárást használják, hanem csináltak egy sajátot, ami gyorsabb.
(#40) LionW: A Voxel GI eleve nem ray tracing ebben a programban, hanem raszterizáció. RT-t egyelőre csak a visszatükröződés kapott. Persze lehet rá írni RT GI-t is, csak sokkal lassabb lesz, és nem hoz annyi minőséget.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De ez pontosan ugyanaz.
A DXR és a Crytek-féle RT csak abban különbözik, hogy bejárás hogyan van megoldva. A DXR-nél háromszögek vannak BVH gyorsítóstruktúrába szervezve, de ennek van egy olyan hátránya, hogy a háromszög egy rendkívül rossz hatásfokú reprezentáció a BVH-hoz. A Cryteknek annyi a trükkje, hogy nem háromszögekkel dolgozik, hanem régebben csináltak még a voxel cone tracinghez egy voxelizációs eljárást. Ez az SVOTI-jük, és erre csinálnak pár effektet, például a GI-t. Ezt egyedül ők csinálták meg az iparágon belül, ugyanezzel a megoldással mindenki elhasalt, kivéve a Sony, de ők célhardverre (PS4) írták, ott azért egy probléma megoldása nagyságrendekkel egyszerűbb, mint egy rakás, eltérő felépítésű PC-s hardvernél. Na most mivel már volt egy ilyen technológiájuk, PC-s szinten gyakorlatilag egyedüliként, úgy döntöttek, hogy nem foglalkoznak a DXR-es BVH-val, hanem csinálnak maguknak egy olyan gyorsítóstruktúrát, amely már eleve a voxelizált jelenetet dolgozza fel. Ez nekik rém egyszerű volt, ott a voxelizációjuk a motorban, elég csak beolvasni. Ahhoz, hogy ez másnak is működjön, előbb meg kell oldani a voxelizációt, de ahogy írtam, ebbe minden PC-s fejlesztés bicskája beletört.
Azzal, hogy maga a bejárás nem háromszögekre van alkalmazva, azt a hatalmas sebességhátrányt nem nyelik be, amit maga a háromszög, mint problémaforrás adna. Ezt a Microsoft a DXR-nél nem tudja megtenni, mert maga az API futószalagja követeli a háromszöget, mint reprezentációs elemet. Tehát effektíve, ha a jelenet objektumait egy bizonyos mélységű BVH-re fel is bontod, az utolsó szinten is lesz legalább egy olyan háromdimenziós tömb, amibe teszem azt kerül legalább 50-100 háromszög. Azokra mind le kell futtatni az intersectiont, még akkor is, ha a sugár ezekből csak egyet talál el. Ez a feldolgozás problémás és egyben lassú része, nem véletlen, hogy próbálnak a DXR-es játékok erősen spórolni a geometriai részlegességgel, mert van egy mélységlimit a BVH szempontjából, amibe bele kell férni, és ott sem árt, ha egy tömbben nem 100 háromszögre megy az intersection. A Crytek megoldása itt annyiban más, hogy ők már magát a intersectiont voxelekre végzik, és ez nagy előny, mert a voxel nagyon jól paraméterezhető reprezentációs elem, amivel el tudják például érni azt, hogy kis mélységgel is, csupán relatíve kevés vizsgálatra legyen szükség, bizonyos mértékig a geometriai részletességtől is függetlenül. Nekik ez valószínűleg azért fontos, mert a CryEngine egyik nagy fegyvere a geometria hatékony kezelése, de ha a DXR miatt ezt vissza kellene fogniuk mesterségesen, akkor a motor elvesztené azt a képességeit, ami miatt esetlegesen páran licencelnék. Emiatt kidolgoztak egy olyan eljárást, amivel ezt a képességet nem vesztik el, de közben meg is tudják oldani pont ugyanazt, amit DXR-rel csinálnak mások. Mert onnantól kezdve, hogy megvan valamilyen módon a traversal lépcső, az RT többi része már csak shading, és ebben a Crytek megoldása sem különbözik a DXR-től, van miss, closest hit és any hit compute shader, amelyek szépen futnak a multiprocesszorokon, pont ugyanúgy, ahogy az a DXR-en történik. Ezek adják ugye magát az effektet, visszaverődés, árnyék, GI, AO, akármi, ahogy megvan a traversal, onnantól kezdve minden megoldás ugyanaz.A fentiek miatt a Crytek megoldása is képes pontosan ugyanarra, amire a DXR, hiszen csak shadereket kell ehhez írni. Ha széttörik valami, az se gond, ugyanúgy látszani fog a visszaverődésnél, egymásra is tudnak hatni. Egyszerűen csak a compute shadert kell rá megírni, de mivel maga a működés ugyanúgy a miss, closest hit és any hit opciókra épít, így bármelyik DXR-re írt compute shader felhasználható a Cryteknek is. Persze annyi különbség van, hogy a DXR megköveteli a DXIL-t, míg a Crytek megoldása a D3BC kóddal is elvan, de ez igazából csak egy újrafordítás, valós jelentősége nincs. Az egyetlen dolog, ami miatt a Crytek ezt választotta, az a nagyobb sebesség, illetve kevesebb limit. A többiek pedig azért nem választják ezt, mert a CryEngine-ben benne van a működés alapjául szolgáló SVO, ami szinten mindenki másnak hiányzik.
Egyébként a Crytek is tud majd hardveres gyorsítást használni ezzel, most még nem hasznos, mert a saját megoldásuk gyorsabb a DXR aktuális hardveresen gyorsított megoldásánál. Viszont a DXR 1.1 már elmozdul a programozhatóság irányába, ami például a Cryteknek pont jó, mert bizonyos problémákat rá tudnak ereszteni a fixfunkciós hardverre, anélkül, hogy a technológiájuk hatalmas sebességelőnyéről le kellene mondaniuk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mi beszélünk róla. Csak nem érted, hogy mi az. Az SVOTI RT az nem SVOTI RT. Az SVOTI a Cryten voxel cone tracing global illumination eljárásának a neve. Ők total illuminationnek hívják, igazából édesmindegy a neve. Az SVOTI-nak ebben nincs igazán szerepe. Ebből csak az SVO az érdekes, mert ez az alap arra, hogy voxelizáld a jelenetet. Aztán ha már ez kész van, akkor ezt felhasználhatod például a global vagy total illuminationre, a név itt mindegy, az effekt ugyanaz. Viszont az SVO felhasználható arra is, hogy erre építsd fel az miss, closest hit és any hit shaderekre épülő sugárkövetést. Ahhoz, hogy ideig elérj, szükséged van egy traversal lépcsőre, ez sok fázisból áll, de a lényege nagyon leegyszerűsítve az, hogy amikor kilövöd a sugarakat, akkor azokat ne kelljen csekkolni az összes háromszögre vagy az összes voxelre, mert az kicsit kurvára időigényes. Emiatt felépítesz egy gyorsítóstruktúrát, amiben a modellek egyes elemeit egy tömbbe rendezed. Ekkor kapsz egy rakás háromdimenziós dobozt, kvázi téglalapot, és a BVH mélységétől függően, szépen le tudod tesztelgetni, hogy melyik dobozt metszi a sugár. Amelyiket nem, ott már a háromszögek vagy voxelek sem lényegesek, mert a dobozon nem megy át, így tuti, hogy azon belül nem talál el semmit. Na ez az a pont, ahol a DXR és a CryEngine másképp dolgozik. A DXR-nél ez a dobozolás a háromszögekre vonatkozik, míg a CryEngine esetében a voxelekre. A DXR ezt nem tudja támogatni, mert maga a grafikai futószalag, amit a DirectX 12 specifikál nem értelmezi azt, hogy mi az a voxel. Tehát bármennyire is sokszorosan hatékonyabb ez a traversal lépcső voxelekkel, DXR alatt nem alkalmazható, az aktuális specifikációkkal, ezért a DXR a nagyon rossz hatékonyságú háromszögekre van kényszerítve. Ezzel azt akarom megértetni veled, hogy bármi, minden, akármi ami megcsinálható DXR-ben, megcsinálható itt is, mert a sugárkövetés effektekre lebontott része a dolgoknak ugyanaz, amint megvan a sugárra vonatkozó intersection eredménye futhat rajta a miss, closest hit vagy any hit shader. Az egytelen különbség, hogy a CryEngine a traversal esetében egy voxeles megoldást használ, mert ez sokkal gyorsabb, bármelyik háromszöges megoldásnál, még a fixfunkciós hardvereknél is. Igen sajnos, ennyire rossz hatékonyságú a háromszöggel a sugárkövetés, de ugye a háromszögek eleve a raszteriáció miatt kellenek, a sugárkövetés támogat más felületeket is. Ezek azok a trükkök, amik miatt előfordulhat, hogy egy-egy offline render engine bár lényegében ugyanazt csinálja, a sebesség tekintetében nagyon-nagyon-nagy lehet a különbség.
Amiért mérvadó, amit itt bemutattak az az, hogy maga az alap már ki van számolva a traversal során. Az, hogy innen a miss, closest hit és any hit shaderek tekintetében hány effektet írsz, gyakorlatilag mindegy. Működésben tehát különbözik a CryEngine a DXR-es megoldástól, de ha azt nézed, hogy végeredményben az a lényeg, hogy melyik háromszöget lövi át a sugár, akkor pontosan ugyanúgy megmondja a Crytek megoldása, ahogy a DXR is. Csak a Crytek rendszere gyorsabban és hatékonyabban megmondja ezt. És innentől már az egész csak effekt, felhasználód ezt az információt, hogy csinálj visszaverődést, árnyékokat, GI-t, AO-t, akármit. Ez innentől kezdve már az lebegőpontos ALU-kon fut. Amiért a Crytek csak visszaverődést csinált, annak az az oka, hogy ez az az effekt, ahol a sugárkövetésnek valós előnye van. Tehát nem csak abban látod a bekapcsolását, hogy egy számjeggyel kevesebb az fps, hanem a képen is meglátszik, hogy számol valamit a gép. Más effekt esetében nem feltétlenül van előnye a sugárkövetésnek, mert AO-ból alig van különbség egy jelenetszintű, vagy egy olyan multi-view megoldás között, amit a Crytek használ, GI dettó, ott eleve voxel cone tracinggel dolgozik a CryEngine. Tehát lehet, hogy ezeket meg lehetne írni RT-vel is, csak nem látnád az előnyét neki a képen, viszont sebességben kevesebb lenne, amit éreznél. Az árnyékok kérdése necces, mert ott azért lehet előnye az RT-nek, de a CryEngine pont az a motor, amely hihetetlenül jó ebből a szempontból, tehát bőven van esélye, hogy ott se látnál mást, csak az fps csökkenését. A visszaverődés viszont egy olyan dolog, ami nagyon nehezen oldható meg raszterizációval. A rough felületre talán lehetne valami trükk az SVO miatt, de specular szinten látszana, hogy nem az igazi. Az SSR-nek pedig megvannak a korlátjai, míg a reflection probe zabagép. Tehát specular visszaverődésre nem nagyon van más értelmes megoldás, mint az RT. Főleg azzal a sebességgel, ahogy a CryEngine csinálja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem az SVOTI a lényeg, az egy GI effekt. Ami itt a lényeg az az SVO, amiből ez az egész működik.
De ez ugyanolyan szintű RT, mint ami van a DXR-es játékokba. Maga a traversal nem is oldható meg máshogy. Ott arra keresed a választ, hogy a kilőtt sugár, a meghatározott hosszig eltalál-e valamit, mit talál el leghamarabb, és még miket talál el. Erre a három kérdésre ad választ a traversal. Az, hogy ezt DXR-rel csinálod, vagy egy sokkal hatékonyabb implementációval, ahogy a Crytek csinálja, a végeredmény szempontjából mindegy, mert amint megvan a válasz a kérdéseidre, amik mindegyik megoldásnál ugyanazok, máris futtathatod a miss, closest hit és any hit shadereket. Ilyen szempontból tehát nem lehet más működésű sugárkövetést alkalmazni, mert a kérdés mindig ugyanaz, és ugyanolyan válasz kell. Az viszont már meg lehet határozni, hogy a válaszhoz mennyire gyorsan jutsz el. A Crytek nem volt elégedett a DXR sebességével, így írtak maguknak egy olyan megoldást, ami gyorsabban ad választ a fenti kérdésekre. Mindössze ennyi a különbség.
Teljesen mindegy, hogy hány effektet raksz bele. Mindegyik arra a kérdésre épül, hogy a sugarak hosszig eltalálnak-e valamit, mit találnak el leghamarabb, és még miket találnak el. Ha ezt meg tudja oldani a beépített traversal, akkor ezer RT effektet is be lehet rakni. A kérdés itt már az, hogy megéri-e. Mert sokszor a raszterizáció nem ad rosszabb eredményt, viszont nem felezi a sebességet, utóbbi kulcstényező. Most a Cryteknek nem sok értelme lenne RT GI-t számolni, amikor az SVOTI-jukkal nagyjából megegyező minőséget kínálna. Az egyetlen különbség, amit látnál, hogy RT-vel nem 10, hanem 60%-ot esik a sebességed. Bizonyos fejlesztő számára ennek van értelme, mert nem tudták megoldani, hogy legyen a motorban egy normális voxelizáció, ezt lentebb részletezem, hogy miért.
Írtam is a fenti hsz-ben, hogy többen probálkoztak voxel cone tracinggel, csak egyedül a Crytek jutott el addig, hogy működjön is. A VXGI addig jutott el, hogy full statikus jeleneten működött, de amint megmozdult valami, összefosta magát. Gondolom láttad az NV-nek a Maxwellhez kiadott holdas demóját. Meg se mozdult benne semmi. Jó okkal, nem működött a technológiájuk, ha az objektumok animálva voltak. A Crytek SVOTI megoldásának az az előnye, hogy működik akárhogy, nem számít, hogy van-e animáció. A többiek is itt buktak amúgy bele, ahol az NV. Ezen csak a Sony tudott felülkerekedni, de csak úgy, hogy egy fix hardverre írták meg, amúgy PC-re nem tudták volna portolni. A problémának köze lehet ahhoz, hogy a voxelizációt mindenki a GPU-n csinálta, és úgy adta vissza munkára a CPU-nak, majd ment vissza az eredmény a GPU-nak. Ez túl nagy round trip volt. A Crytek a voxelizációt magán a CPU-n csinálja, és csak CPU->GPU irányú feldolgozás van, nem pedig GPU->CPU-GPU. A Sony ezen a megosztott memóriával kerekedett felül, így round trip ugyan volt, de adatmásolás nem.
(#51) dabadab: Nem, a Crytek megoldása nem csalás. Egyszerűen csak nem háromszögeken dolgozik, de ennek jó oka van, a háromszögek eléggé rossz megoldásnak számítanak RT-re. Viszont a Microsoft ezt nem tudja megcsinálni, mert a DirectX futószalag a raszterizáció miatt csak háromszöget kezel. Viszont maga az eredmény szempontjából a Crytek megoldása ugyanúgy megmondja egy sugárról, hogy eltalál-e valamit, mit talál el leghamarabb, és mit talál még el. Ugyanezt csinálja a DXR is, és alapvetően csak erre keresed a választ, hogy utána futtatni tud a shadereket.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De nem is mozog semmi a jelenetben, aminek a tükörképe mondjuk nem tudna megjelenni.
Mondjuk erre is van megoldás, például a reflection probe, csak az meg nem futnak GeForce 2 MX-en. 
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Mondjuk erre is van megoldás, például a reflection probe, csak az meg nem futnak GeForce 2 MX-en. 
Új hozzászólás Aktív témák
ph Az idei GDC-n bemutatott Neon Noir gyakorlatilag minden, DirectX 11-et támogató grafikus vezérlőn fut.
- Vírusirtó topic
- Rossz üzlet az EV-kölcsönzés
- MIUI / HyperOS topik
- A személyre szabott reklám lehet a streaming következő slágere
- EAFC 24
- Retro teló rajongók OFF topicja
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Van, amit nehéz lett megtalálni a Google keresőjével
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Pécs és környéke adok-veszek-beszélgetek
- További aktív témák...
