- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Samsung Univerzum: Így ismerhető meg a Galaxy AI bármilyen telefonon
ma A Try Galaxy webalkalmazás kontrollált környezetben mutatja meg, mit tud a One UI 6.1-es rendszer és a mesterséges intelligencia.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A Raytracing fantasztikus, az egy rendkívül fontos lépcső lehet a jövőben, hogy a grafikai színvonal előrelépjen. De meg kell érteni, hogy ez egy rendkívül erőforrás-igényes eljárás. Nem véletlenül számolnak még ma is egy bonyolultabb jelenetet órákig a hardverek. Ez egy első lépés, amit nyilván nehéz úgy megtenni, hogy a játékot eleve nem tervezted sugárkövetésre, és emiatt nagyon komplex a geometria. A jövőben erre lehet figyelni, hiszen a geometriai részletesség a sugárkövetés érdekében visszafogható, így pedig jobb eredmények jöhetnek ettől. A Shadow or the Tomb Raider is tartalmaz konfigurálható geometriai részletességet, ami tényleg sokat javíthat a sugárkövetés teljesítményén.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#214
Abu85
HÁZIGAZDA
huskydog17
#207
Abu85
HÁZIGAZDA
válasz
huskydog17
#207
üzenetére
Jézus ereje. 10 éve velünk van a DirectCompute és nem tudtunk még rá gyors implementációt írni?
Én elhiszem nekik, hogy ilyen bénák, te? Gondolom sokaknak azért kiakadt a "damage control" mérője. Két dolog lehetséges, csökkentik a geometria részletességét, vagy kevesebb sugarat generálnak valahogy. A ray-tracingnek az az előnye, ami a legnagyobb hátránya is. Annyira általános maga az eljárás, hogy nem nagyon lehet mit rajta optimalizálni.Az valóban igaz, hogy a Redstone 5-ben egy másik specifikáció lesz, de nem azért, mert az gyorsabb, hanem azért, mert össze lesz vonva a fallback layer és a natív implementációk. Ez azt jelenti, hogy egy kódból lehet kiszolgálni mindent, de a mostani specifikációhoz képest a rendszer elveszti a hardverspecifikus optimalizáció lehetőségét. Értsd ezt úgy, hogy a hardverben található, egyes feladatokra dedikált egységek a Redstone 5-től már nem látszanak az API-ban és kiegészítéseiben. Ezeket nem lehet direkten címezni a program oldaláról, csakis az API alatti implementáció fogja elérni őket. Ez ugyan elveszi a program oldali optimalizálás lehetőségét, de mégis okkal lépte meg a Microsoft, mert ha mondjuk most írnának az NV-re egy optimalizált kódot a fejlesztők, és megjelenik az RTX 3000 sorozat egy módosított hardverrel, akkor az NV-re írt kód azon már nem fog futni. Az új specifikációval a hardveres optimalizációk elvésznek ugyan, de ha jön majd az RTX 3000, akkor a mostani kódokat is futtatni tudja. Persze ez a megoldás lassabb, de a kompatibilitás itt többet ér, mint a sebesség. A maradék teljesítményt a DirectCompute meghajtó határozza majd meg. És remélem nem baj, ha egészséges kétkedéssel fogadom, hogy az NVIDIA az elmúlt tíz évben nem tudta annyira optimalizálni, hogy majd a következő pár hétében 30-50%-os teljesítményt találnak benne, mert ennyit minimum találni kellene, hogy a 30 fps-ből 35 legyen.
Innen ami realitás, amivel tényleg lehet sebességet nyerni az az effekt vagy a játék butítása, utóbbi esetben a geometriára gondolva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Dehogynem. Nem muszáj minden pixelből lőni, lehet mondjuk négyes pixelblokkokból. Rögtön óriásit javítottal a teljesítményen. Persze a kapott eredményt utókezelni kell majd. A DICE ezt csinálja.
A DXR a DirectCompute API-n, ennek is a shader modell 6.x-es verzióján futtatja a DXR shadereket. Ezért kötelező hozzá a DirectX 12, mert DXIL IR-eket fogad csak el a rendszer.
És mit optimalizálsz egy DXR shaderen? Van ugye öt fajta a pipeline-ban: ray gen., intersection, miss, illetve closest- és any-hit. Ezekkel kontrollálod az egészet. Maximum vigyázni tudsz, hogy ne szemeteld össze a cache-eket, de ha megteszed, az már rég rossz. A HLSL specifikáció pedig gyakorlatilag a compute shader 6.0, kiegészítve traversal és state függvényekkel.
(#222) Jack@l: Hol optimalizálnak? A többi az fallback layer vagy ASIC.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#226
Abu85
HÁZIGAZDA
ForRedGlory
#225
Abu85
HÁZIGAZDA
válasz
ForRedGlory
#225
üzenetére
Mert előbb meg kell várni, hogy a Redstone 5 megjelenjen. A Redstone 4-nél más a DXR specifikációja. Ott a gyorsításra vonatkozó hardverek elérése a program oldaláról is megoldható, így szénné is lehet optimalizálni mindent, de mivel a Microsoft egységes platformot akart, így a Redstone 5 egy olyan DXR specifikációval jön, ami elveszi a fejlesztőktől a hardverek direkt elérését, és alapvetően egy egységes alapot kínál arra, hogy egyetlen kóddal támogassák a fallback layert, illetve a natív implementációkat. Ettől a verziótól kezdve a natív implementációk kezelik a hardverek specifikus funkciót, vagyis az aktuális kódok, ahol ezt az alkalmazás oldaláról is meg lehetett tenni, nem lesznek kompatibilisek. A jövő szempontjából ez fontos, mert így garantált a kompatibilitás, ha jön a jövőben egy rakás új hardver. Cserébe a natív implementációk egy kicsit vesztenek a teljesítményükből, mert kevésbé célozhatók ideálisan, de a kompatibilitás miatt ezt az áldozatot érdemes bevállalni. Főleg úgy, hogy ha nem ilyen lenne a specifikáció, akkor a jövőre érkező hardveren nem biztos, hogy futnának a kódok. Az új DXR-rel viszont biztos.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#256
Abu85
HÁZIGAZDA
huskydog17
#228
Abu85
HÁZIGAZDA
válasz
huskydog17
#228
üzenetére
És mi lesz szeptember 20-án? Tényleg játsszuk le lépésenként. Megjelenik az RTX 2080 és a Ti verzió. A Tomb Raiderhez kiadnak mondjuk egy patch-et. Mit kezdesz a patch-csel, amikor nincs benne a Windows 10-ben az a futtatási környezet (DXR1.0), amely egyáltalán értelmezni tudja a leszállított kódot? Oké rendben, hogy van DirectCompute. Az nem fog megváltozni. Megvan a shader modell 6.x is, 6.1 legalább, de a HLSL 2018-as specifikációból a legújabban kell írni a kódot, mert a Redstone 4-ben, vagyis a mostani Windows 10-ben található implementációk nem fogják ismerni a DXR1.0 függvényeit. Jó felismerik a DirectCompute függvényeket, ami persze a kód jelentős része, de amint szembejön mondjuk egy TraceRay (és jönni fog, mert "ki kell lőni" a sugarakat), illedelmesen ki fogják csapni a képernyőre egy üzenetben, hogy "mi a tököm ez a szar, ilyen nincs is". Szóval ennek tudatában mit vársz szeptember 20-án?
Jelen pillanatban a DXR0.9-es verzió van beépítve a Windows 10 Redstone 4-be, ami csak akkor aktiválódik, ha devmode-ban van az OS. Enélkül hozzá se nyúl. Ráadásul fontos, hogy az új specifikáció egységesített, vagyis a jelenlegi natív, hardverhez közeli implementációkból egy csomó funkció eltűnik. Le se lesz szállítva a Redstone 5-ben, mert azokkal a fixfunkciós hardvereket lehetett az API-ból, illetve a specifikus kiegészítésekből elérni, de a végleges specifikáció a fallback layerhez van írva, és a hardvert az API alatti implementáció fogja elérni natívan (ha lesz ilyen, mert nem kötelező), így a fejlesztők is csak a fallback layert tudják célozni, szemben a mai helyzettel, amivel külön kód kell a fallback layerhez, illetve a hardveres megoldásokhoz. Tehát a ma futó kódok jórészt használhatatlanok a Redstone 5-höz, mert a natív hardverelérés átkerül az API szintjéről az API alá. Emiatt egy rakás funkciót még ki is kell műteni a startig, az ehhez kapcsolódó optimalizálásokat törölni kell, vagy újra kell írni, mert ha nem teszik meg, akkor szintén csak nézni fog az OS-en belül futtatási környezet, hogy mi a túrót akar a program tőle. Tehát nem azért jönnek ezek patch-ben, mert hú de szét lehet még őket optimalizálni, és a GeForce-ok startjáig úgyis van idő, hanem azért, mert a Microsoft megváltoztatta a régi specifikációkat, így egy rakás kódot át kell írni, hogy ezek a tényleges futtatási környezettel, nem a tesztverzióval, hanem a véglegessel, vagy ahhoz közelivel, egyáltalán fussanak is. Mert ha a mostani kódokat a Redstone 5-re ráengeded, akkor az OS néz rád, te nézel az OS-re, és csak lesitek, hogy miért nem megy.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#281
Abu85
HÁZIGAZDA
huskydog17
#278
Abu85
HÁZIGAZDA
válasz
huskydog17
#278
üzenetére
És mi a teóriám? Mert én nem fogalmaztam meg ilyet. De, ha így leírtad, hogy van, akkor érdekelne, hogy mi az.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#283
Abu85
HÁZIGAZDA
huskydog17
#282
Abu85
HÁZIGAZDA
válasz
huskydog17
#282
üzenetére
Akkor hívjuk tényeknek vagy teóriáknak, de mik azok, amiket írtam, és szerinted teória?
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#286
Abu85
HÁZIGAZDA
huskydog17
#285
Abu85
HÁZIGAZDA
válasz
huskydog17
#285
üzenetére
Én nem állítottam ilyet. Azt állítottam, hogy szimplán optimalizálásból nem fognak tudni sebességet nyerni úgy, hogy a DXR-ből végül kikerült a hardverek API oldaláról történő elérése. Akkor nyerhetnek sebességet, ha butítanak az effekten, például nem pixelenként lőnek sugarat, hanem négyes pixelcsoportonként, vagy maga a sugár nem pásztázza a jelenetet olyan sokáig (megszabható a virtuális hossza), vagy visszaveszik a geometriai részletességet.
A Redstone 5 meséket konkrétan a Microsoft mondta el a SIGGRAPH-on. Garanciát nem vállaltak, de: "- On RS5, DirectX Raytracing should be integrated"
De amúgy, tegyük fel, hogy hazudtak. Hogyan képzeled el a DXR-t? Mert annyira nem törte össze magát a Microsoft azon, hogy a Redstone 3 előtti frissítésekre elvigye a shader modell 6-ot, ráadásul minden egyes új shader modell verzió új frissítést igényel. A 6.1-hez már Redstone 4 a minimum. A 6.2-höz ez alapján a Restone 5 lesz, de a remény hal meg utoljára. Mondjuk a DXR szempontjából mindegy, a futtatási környezetet vagy a Restone 5-ben, vagy jövő tavasszal a Restone 6-ban szállítják. Valószínűleg az 5-ben, mert hát badarság lett volna bemutatni ezt, ha csak jövő tavasszal lenne lehetőség futtatni a programokat.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Én elhiszem nekik, hogy ilyen bénák, te? Gondolom sokaknak azért kiakadt a "damage control" mérője. Két dolog lehetséges, csökkentik a geometria részletességét, vagy kevesebb sugarat generálnak valahogy. A ray-tracingnek az az előnye, ami a legnagyobb hátránya is. Annyira általános maga az eljárás, hogy nem nagyon lehet mit rajta optimalizálni.
Új hozzászólás Aktív témák
ph Sugárkövetéssel Full HD fölött ne nagyon gondolkodjon senki, legalábbis a Shadow of the Tomb Raiderben semmiképp.
