Hirdetés
- Feháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasgatni
- A luxusmárkáknak kell a bitcoin, az USA jegybankjának nem
- Letiltja az USA a politikusokat a telefonhívásokról és szöveges üzenetekről
- Nagy áttörés jön a napelemek piacán, nem kell annyi hely a paneleknek
- Belenyúlt az USA az Epic Games igazgatótanácsába, nyomoz az NVIDIA
- Windows 10
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Tényleg betilthatja a TP-Linket az USA
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Milyen routert?
- Jelszókezelők
- Mozilla Firefox
- KAÜ/Ügyfélkapu – már elérhető a kétfaktoros hitelesítés
- Mikrotik routerek
- Feháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasgatni
-
IT café
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Pedig pont ugyanannyit tud a hardver. A különbségek szimplán szoftverből erednek. Az AMD nem engedélyezi az exkluzív cache módot a driverben a Navi-ra. De a hardver amúgy támogatja, hiszen az exkluzív cache mód az egyszerűsített, jelentősen lecsupaszított verziója az inkluzív cache módnak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Amit írsz az arra utal, hogy nem érted. A HBCC lényeges része nem az exkluzív, hanem pont az inkluzív cache mód. Ez a default működése a technológiának, mert itt érhető el a hierarchikus lapozás. Ebben a módban bármelyik, a rendszermemória shared területén található lap becache-elhető a HBC-be, és ettől válik maga a dizájn annyira hatékonnyá. Ezt az eljárást használja a két új konzol is.
Az exkluzív cache mód csak egy kiegészítés. Azért jött, mert az inkluzív cache módot az alkalmazás oldaláról kell támogatni, míg az exkluzív cache mód engedélyezhető driverből is. Hátránya, hogy nem támogat hierarchikus lapozást, illetve a HBCC szegmens kötöttsége miatt az alignmentálása sem tökéletes. Például bőven előfordulhat, hogy a shared memory nem pont a HBCC szegmensbe kerül. De ugye annyira rossz hatékonysággal működik már maga a szoftveres menedzselés, hogy még ilyen tetemes hátrányok mellett is előnyösebb tud lenni az exkluzív cache mód. Viszont az inkluzív cache mód hatékonyságát meg sem közelíti.Az inkluzív cache mód támogatásához AGS kell PC, nem API oldali kiegészítés. Ahhoz kell külön API, amikor magáról az SSD-ről lesz beolvasva az adat a GPU számára. Például a konzoloknál. Erre amúgy PC-n is van megoldás, ez az SSG API.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért nem érted, mert iszonyatosan kevered a neveket. A HBC maga a technológia neve. A HBCC a vezérlő neve, amitől ez a technológia működik, míg az inkluzív és az exkluzív cache mód az a kétféle mód, amiben maga az alaptechnológia működhet. Na most mindkettő ugyanazt a vezérlőt használja, tehát ahhoz, hogy az inkluzív cache móddal működjön a HBC, muszáj támogatni a HBCC-t, mert másképp nincs ott a vezérlő, amivel működni tud. Tehát a HBCC-t támogatja a Navi. Maga az exkluzív cache mód nincs engedélyezve a driverben.
Nem a régi kártyák miatt nincs benne a driverben. A WDDM-nek vannak vele stabilitási problémái. Például előfordulhat, hogy ha sűrűn állítod át ezt a paramétert, akkor úgy belefagysz a Windows-ba, hogy többet nem jön be az OS. Ritka, de sajnos lehetséges, és akkor újra kell telepíteni a rendszert a rendszerpartició formázásával. Erre készül egy új WDDM verzió, amivel már ez nem történhet meg. Addig is inkluzív cache mód van, az biztonságosan használható.
A Vegából azért nem vették ki, mert fícsőrként el volt adva, és maga az alapprobléma rendkívül ritka, kvázi laborkörülmények kellenek hozzá.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Van. Benne van a dizájnban. Az exkluzív cache mód nincs engedélyezve a driverben. Az inkluzív cache mód viszont szabadon használható, arra megvan a rutin a meghajtóban. Az AGS-sel lehet használni.
Én csak leírom, hogy van HBCC, nehogy az maradjon meg az emberekben, hogy nincs. Olyan ez, mint anno az, hogy a Navi egy RDNA+GCN hibrid. Egy csomó ideig nyomták a bullshitet a
WCCFtechen, aztán kiderült, hogy semmiféle GCN nincs benne. Ezt is leírtam jó előre. Ne terjesszünk fals információkat, mert felesleges.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De elérhető. Erre van az inkluzív cache mód. Az exkluzív cache mód nem érhető el. Ezzel elég sok baja van a mostani WDDM verzióknak, valószínűleg ezért nem engedélyezi az AMD. A Microsoft csinál éppen módosításokat a Windowsba, hogy az új WDDM ne legyen annyira érzékeny rá.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Van HBCC a Naviban is, csak nem engedi az AMD bekapcsolni driverből az exkluzív cache módot. De ettől a technológia hardveresen még ugyanúgy ott van, és inkluzív cache módban például elérhető.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26914
üzenetére
Nem az NVIDIA a hibás ebben. Igazából senki, meg nem is igazán spórolás ez. A TSMC-nél van egy olyan gond, hogy túlzottan nagy igény alakult ki a 7 nm-es node-ra, és ezért ugye korábban be is vezették, hogy egy évre előre kérik a rendelést. Ez azoknak nem baj, akik már gyártanak ezen a node-on, de azoknak komoly probléma, akik még nem, mert ugye nem tudnak kis mennyiséget rendelni, majd három hónap múlva korrigálni, ha megfelelő a lapkák gyárthatósága. Vagy egy egész évig sokat gyártanak, és ha nem sikerül jól a fejlesztés, akkor gyakorlatilag elégetnek egy rakás pénzt, vagy keveset rendelnek, és akkor meg nem lesz reálisan elérhető termék. A TSMC korábban ilyet nem csinált, nekik mindig is három hónap volt a rendelési ciklus, és az igazodott az iparági normákhoz, mert megszokott, hogy egy új fejlesztésnél, amikor még a megrendelő sosem használta az új node-ot, három hónapig kis mennyiséget rendel, hogy ha valami gubanc van, akkor kevés pénzt kelljen elégetni. És ha minden rendben alakul, akkor három hónap múlva jelentősen meg lehet növelni a rendelési tételt. Na most ez a három hónapos ciklus a TSMC-nél egy év lett, és ilyen időtartamra már nem lehet jól tesztelni a node-ot. Emiatt az NV azt csinálja, hogy a nagyon nagy GPU-kat a TSMC-hez elviszi. A Tesla esetében úgyis annyira magas az eladási ár, hogy még ha baj is lesz a TSMC-nél, akkor is ki tudja magát gazdálkodni a fejlesztés, és eközben megismerhető a 7 nm-es node. Ehhez elég egy lapka is.
Most már a FinFET is közelít a végéhez, tehát jönnek vissza a pipe-cleanerek, mert egyre nehezebb egyből betalálni. Ezek a megoldások régen nagyon elterjedtek voltak, de a 16 nm-től kezdődően megszűntek, aminek az oka az volt, hogy a FinFET struktúra nagyon működött, de ugyanúgy, ahogy anno a bulk, úgy a FinFET is el fogja érni a határait, és a határokhoz közel érdemes tesztlapkát tervezni. Erről az NV különösen sokat tudna mesélni, hiszen anno a Fermivel pont kockáztattak, és orra is estek, tehát nem véletlen, hogy az adott struktúrák határait feszegetve sorra előjönnek a pipe-cleaner lapkák. Az AMD sem talált be egyből, hanem úgy néz ki, hogy csak harmadikra fognak, mert hiába tervezték meg a 7 nm-es GPU-dizájnokat 2 GHz fölé, egyik sem igazán működik így. De az RDNA2 már elég szépen jár 2 GHz fölött. Viszont ehhez két puskaport ellőttek 7 nm-en (Vega 20 és Navi 10), mire sikerült áttörést elérni. Ez már egyértelműen abból a problémából ered, hogy a FinFET nehezen kezelhető ezen a csíkszélességen. Abszolút nem triviális, hogy mit kellene csinálni ahhoz, hogy a tervezett órajel meglegyen. Ugyanezzel a problémával küzd az Intel is a 10 nm-es node-jánál. Az is nehezen ér el magas órajeleket, és legalább két-három kör, mire rájönnek a mérnökök, hogy mi az optimális paraméterezés. Lassan a Tiger Lake-nél nagyjából meglesz, de igazából az Alder Lake fog jó órajelekkel dolgozni. Szóval lehet itt modern csíkszélességre váltani, de a FinFET határainál felmerül a kérdés, hogy biztos megéri-e. Mert könnyen lehet, hogy a célzott órajel még csak megközelítőleg sem lesz meg, és innen nézve már eléggé baráti egy jobban ismert node, amiről elég sok a tapasztalat. Lehet, hogy egységnyi területbe nem fér bele annyi tranzisztor, de legalább kis kockázattal lehet rá tervezni.
(#26915) Jack@l: Mert a Samsungnál készült tokozást használnak az OEM-eknek eljuttatott minták. Arról nagyjából be lehet azonosítani a node-ot, hogy hol lettek tokozva. Persze nem pontosan, de például az EUV-s node-on készült lapkákat máshol tokozza a Samsung, mint a nem EUV-seket. Az meg nagyon ritka, hogy a Samsung TSMC-nél készült lapkákat tokozzon.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
adamssss
#26910
üzenetére
A Teslákra biztos. Ez egy tuti forrás. A 10 és a 8 nm a kérdéses, de a tömegpiacra szánt gaming cuccok a Samsungnál készülnek, és nem EUV-s node-on. Tehát vagy 10 vagy 8 nm, de mindegy, hogy melyik, mert a 8 az a 10-nek a half node-ja, tehát gyakorlatilag ugyanaz, attól eltekintve, hogy kisebb a szám a nanométer előtt.
(#26911) GeryFlash: A kódjelzés alapján inkább 10 nm-esek voltak azok a dizájnok, de ez tényleg mindegy, hogy 8 vagy 10. Ez csak szám szerint hangzik nagy különbségnek, valójában alig van eltérés. Annyi a lényeg, hogy a Samsung a 10 nm-es eljárást általánosabbra tervezte, tehát a high performance rendszereknek is kedvez benne, míg a 8 nm-es half-node kizárólag ultramobil fókuszú, nem képes nagyon magas órajelekre, de jobb a hatékonyság.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26903
üzenetére
Sokkal bonyolultabb a sugárkövetés annál, hogy mátrixszorzással és összeadással megoldható legyen. Elég komplex probléma. Leginkább a denoisinghoz kell rengeteg mátrixszorzás, de máshoz azért jóval több kell ennél a műveletnél. Már csak azért is, mert ha nagyrészt a probléma mátrixszorzásból és összeadásból állna, akkor nem kellene hozzá dedikált hardver, hiszen pont ebben a két műveletben kiemelkedően hatékonyak amúgy is a GPU-k.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AC Unity mindenen rosszul futott. A technológiák ugyanakkor megmaradtak belőle, és az új AC részek is ugyanúgy a multiprocesszorokon futtatnak egy csomó, PC-n amúgy CPU-n futó szimulációt. Ezért tudnak ezek a játékok futni a konzolokon.
Nem merül ki ebben a PC-s processzorigény, csak az AC-k nem kínálnak explicit API-t, így nem tudják skálázni a teljesítményt. Ettől függetlenül már érezhető előnye van ezekre a játékokra is a nyolc magnak.
A Planetside 2 esetében a fejlesztők nem gondolkodtak el azon, hogy a proci mellett egységes memóriával van egy rakás bivaly multiprocesszor. A lényeg annyi, hogy a konzol egy nagyon speciális környezet. Egy csomó olyan dologra képes vagy, ami PC-n egyszerűen lehetetlen. A valós limit csupán a HDD, de az megoldhatatlan. Ott nincs mivel helyettesíteni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
gejala
#26834
üzenetére
Nem az NPC száma a lényeg, abból berakhatsz ugyanannyit a mostani és a next-genbe is. Az AC játékok is tele vannak NPC-vel PS4-en. Annyit csinál az Ubisoft, hogy amíg PC-n ezek szimulációjáért minden szempontból a CPU felel, addig konzolon egy csomó elem át van rakva az IGP multiprocesszorára. Egy multiprocesszor simán ad neked annyi számítási kapacitást, amennyit egy mai 8-magos csúcsproci, és a memória is egységes, tehát nincs CPU round trip.
Az előző generációs konzolok egyáltalán nem a CPU-ban jelentik a limitet, mert azt bőven lehet ellensúlyozni a bivalyerős multiprocesszorokkal. A valós limit a HDD lesz, mert a HDD-ről való streaming lassúságát semmivel sem tudod kezelni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Atom_Anti
#26813
üzenetére
Jelen pillanatban nem igazán probléma a CPU-limit. Explicit párhuzamos parancsátadást kínálnak az új API-k, és 64-magos processzort is vehetsz a gépbe, ha elég mély a pénztárca. Ez a jelen korban nem probléma. Egyszer talán megint az lesz, de nem a közeljövőben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26795
üzenetére
Nem CUDA, hanem OptiX. Ez backend kell ahhoz, hogy a fixfunkciós blokkok működjenek. Ezen keresztül viszont nincs interoperabilitás a fixfunkciós blokkokra egyik grafikus API-val sem. Ilyen formában ez a megoldás nem támogat hibrid módokat, vagyis olyan feldolgozást, amikor a grafikai számítás egy része raszterizálás. Elsődlegesen amiatt, mert nincs megtervezve az interoperabilitás szabványos grafikus API-kal. Az OptiX backend lényegében arra jó, hogy be tud építeni a fixfunkciós egységek támogatását a meglévő, CUDA-ra írt render engine-ökbe.
Specifikusan a Crytekre kitérve nem elhanyagolható az sem, hogy a CryEngine nem támogat CUDA-t, és enélkül ugye nincs OptiX sem.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#26794
Abu85
HÁZIGAZDA
huskydog17
#26792
Abu85
HÁZIGAZDA
válasz
huskydog17
#26792
üzenetére
Ha visszaolvasok, akkor meg tudod keresni, hogy több hsz-szel korábban is pont arról írtam, hogy a DXR 1.1 már megérheti a Cryteknek, mert az gyorsabb lehet. Például itt: [link]
A DXR 1.0 tartalmaz olyan erős limitációkat, ami a CryEngine számára pont nagy probléma, mert nem a DXR 1.0-nak megfelelően tervezték a motort. A DXR 1.1 annyiban segít nekik, hogy nem lesz baj abból, ahogy a motorjuk működik, mert az a rengeteg limit, az API-ban végzett fejlesztések hatására eltűnik.(#26793) Yutani: A Neon Noir eleve egy DX11-es program. DX11 alól ezek a fixfunkciós hardverek hozzáférhetetlenek. Ehhez DirectX 12 kell, és ezen belül is egy olyan Windows verzió, ami már tartalmazza a DXR 1.0 frissítést. Esetleg új Vulkan. De a DirectX 11 nem jó, addig nem portolta vissza a kiegészítést a Microsoft.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
#26786
Abu85
HÁZIGAZDA
huskydog17
#26785
Abu85
HÁZIGAZDA
válasz
huskydog17
#26785
üzenetére
Ez itt pont arra vonatkozik, hogy a mostani API-kkal és a mostani hardverekkel nem tudnak többet kihozni a saját rendszerüknél. Egyszerűen túl limitált az a környezet, amit teremtenek a mostani futószalagok, illetve a hardverek is. Ha ebben lenne valami még, akkor támogatnák, hiszen miért is ne lenne érdemes nagyobb sebességet nyerni.
Viszont inline raytracinggel, ExecuteIndirecttel támogatott ray dispatch mellett már a CryEngine is tudna előnyt kovácsolni a fixfunkciós hardveres blokkokból, mert megmaradna a bejárási lépcsőben megnyert teljesítmény, és nem vesztenék el különböző kötelezően benyelendő limitációkon. Nem véletlen, hogy a DXR 1.1 olyan újításokat hoz, amilyeneket. Persze mondhatjuk, hogy az inline raytracing gyökeres váltás a dynamic shader raytracinghez képest, de alapvetően megéri, mert az elején még nem akkora probléma új hardverekre ugrani.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26783
üzenetére
A Zhaoxinnak a VIA révén van licence. Tulajdonképpen a VIA az egyik résztulajdonos.
Az is megoldás az NV-nek, ha eladják magukat, de nem hiszem, hogy ez megtörténik.A reálisabb megoldás, hogy rendelnek egy custom processzort az AMD-től. Azzal, van licenc, és rakhatnak bele NVLinket, mert ugye maga a custom divízió bármit beépít.
Vagy csinálnak maguknak ARM-os processzort.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26780
üzenetére
Semi-customben, ahogy például a kínaiak csinálták, szerintem van. De az a processzor valójában nem lesz az övék, és pont ezért van rá esély. Az AMD letervezi, és egy gyártásra kész dizájnt leadnak a megrendelőnek. Ezt meg tudná tenni az NVIDIA is, és valószínűleg semmilyen politikai korlátba nem ütközne, ahogy például a kínaiaknak tervezett cucc.
Van nekik egy megbízott ügynökségük, ők küldik a blogra kirakott híreket.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Mellanox semmit sem segít az NV-nek azon, hogy az Intel és az AMD HPC győzelmeivel kezdjen valamit. A gondjuk az, hogy nincs x86/AMD64-es szerverprocesszoruk. Az Intel és az AMD ezért nyeri most az exascale projekteket, mert maga a processzoreladás megnyeri számukra a gyorsítóeladást is, hiszen nincs más lehetősége a megrendelőknek. Az NV-nek itt az segítene, ha az Intel és az AMD beleintegrálná a processzoraikba az NVLinket. Amíg ezt nem teszik meg, addig nem tud az NV mit kezdeni velük, mert nem adnak a legelterjedtebb HPC processzorok direkt interfészt a GPU-ikhoz.
A Mellanox network szintjén hasznos, de nem most, hanem amikor majd leterveznek maguknak egy saját HPC processzort, és ők is komplett platformot kínálnak, mint az Intel és az AMD.Benne volt az is, hogy kik mennek, az is, hogy mik jöttek, és az is, hogy mikor indul a kereskedelmi szolgáltatás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26775
üzenetére
Fel. Válaszoltam neki. De korábban leírtam már, hogy ez egy demó, és az NV csak pár GPU-hoz rakott profilt a driverbe. Mivel ez nem programindító fájlhoz van kötve, így nem kapcsol be más GPU-kon.
(#26776) b. : Mellanox-NVIDIA: [link]
Régen volt egy szavazás a driverekről. Abban azt kérték az olvasók, hogy csak a WHQL, a hotfix és a gyártói aláírt driverekről legyen hír. Ehhez tartjuk magunkat minden gyártónál. Nem mellesleg a gyártók sem szeretik, ha megírjuk ezeket a drivereket. Volt egyszer, hogy megtettük, és ideszóltak, hogy inkább ne, mert egy rakás problémát varrunk a nyakukba, ha a juzer felteszi.
RTX Voice-ról lehet még hír, csak nem jutottam még el addig. Nem ezeket küldte az NV, hanem a GeForce Now változásokat, így az prioritást élvezett. És ha ezt a hírt elolvasod, akkor nem csak azt írtuk meg, hogy kikerültek játékok, hanem azt is, hogy bekerültek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26773
üzenetére
Ahogy láthatod a teszteken, mi modern játékokban tesztelünk DX12 és Vulkan API-val, ahol az AMD (főleg a driver miatt) erősebb, mint azokban a játékokban, amelyek nem túl modernek, esetleg DirectX 11-esek (itt is főleg a driver miatt alakul ki ez a különbség csak éppen az NV javára). Tehát alapvetően a hardverek közötti teljesítményt nagyban meghatározzák a játékok. Emiatt előre nem lehet tudni, hogy egy új játék hogyan teljesít. Ha mondjuk DX12 vagy Vulkan leképzőt kap a Crysis Remastered, akkor valószínűleg hasonló lesz a sorrend a mi tesztjeinkhez, ha DirectX 11-est, akkor inkább azokhoz a tesztekhez lesz hasonló a sorrend, ahol főleg DX11-es játékokkal tesztelnek még.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26770
üzenetére
Fentebb leírtam. A DXR 1.0 működése egy csomó limitációhoz van kötve. Többet veszthetsz a limiteken, mint amennyit nyersz a fixfunkciós hardveren. Ha ez nem így lenne, akkor a Crytek is a hardveres megoldást támogatná.
(#26771) paprobert: A Crytek nem. Inkább a Saber, amelyik cég a PC-s portot csinálja. De mindegyik architektúra kap optimalizációt. A Saber eléggé figyelt erre a World War Z esetében is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26765
üzenetére
A Crytek megoldása nem tud profitálni a fixfunkciós hardveres blokkokból. Teljesen másképp működik a rendszer.
Az adott lépcsőre vonatkozóan lehetne több sugár, és az adott lépcső egy fixfunkciós hardveren valószínű, hogy gyorsabb lenne, de máshol keletkeznek olyan limitek, amelyek a teljes képkockára levetített teljesítményt már negatívan érintik. Emiatt használ a Crytek más megoldást, és nem a DXR 1.0-t.
A DXR 1.1 egy csomó olyan limitációt kezel, ami egyébként nagyon fájó, és ezzel már jó esély van arra, hogy a Crytek saját megoldásánál is gyorsabb lehet, de ezt be kell építeni, és csak a legújabb, érkező Windows 10-en fut, jó sebességgel az év végén érkező hardvereken.(#26767) gejala: Azért nem. PS4-en még olyan játék is van, ami nem csak ilyen hibrid raszterizálás+sugárkövetést használ, hanem 100%-ban sugárkövetés az egész raszterizáció nélkül. Azért ez nem mindegy, és ez részben annak köszönhető, hogy a hardver azért jóval közvetlenebbül hozzáférhető.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Még mindig nem értitek, hogy messze nem annyira egyszerű a sugárkövetés, mint amennyire leegyszerűsítitek. A GPU-k esetében a raszterizálás azért ideális leképezési forma, mert mindig koherens. A sugárkövetés ezzel szemben az esetek jó részében nem koherens. És itt jön az a probléma, hogy a GPU-k azért tudnak igazán hatékonyan működni, mert a grafikai számítások során ritka, hogy folyamatosan véletlenszerű adatelérés történik. Ezzel szemben a sugárkövetés során igen gyakori. Tehát vannak a sugárkövetésnek egyes lépcsői, és ezeknek a lépcsőknek mások a limitációi, viszont a fő limitáció mindenképpen a memória-sávszélesség lesz. Tehát megteheted mondjuk azt, hogy nem négy, hanem egy pixelenként lövöd ki a sugarakat, tehát effektíve négyszeresére növeled a bejárás lépcső terhelését. A fixfunkciós hardver persze, hogy jobban elbírja, de haszna a valóságban nincs, mert a mintavételre nincs még meg a memória-sávszélesség. Ha meglenne, akkor a Crytek is ezt alkalmazná, de ugye kiértékelték, hogy mire képesek a hardverek és ugyanarra a következtetésre jutottak, mint a SEED a pica-pica tesztprojekt esetében. Egyszerűen még elképesztően limitáltak a hardveres lehetőségek, így hiába vagy gyors a sugárkövetés futószalagjának egy lépcsőjén, ha a megnövekedő terhelés miatt a mintavételre már nincs meg a teljesítmény. És ugye itt a mintavétel véletlenszerű, nincs a hardverekben semmilyen koherenciadetektor, tehát minden, amit mondjuk az architektúra tervezésénél arra építettek fel, hogy a raszterizálásnál építkezhessenek a lokalitási elvre, az hasztalan a sugárkövetés során, mert tele lesz szemetelve a cache a nem koherens sugaraktól. Tehát elhiszem, hogy borzalmasan le akarjátok egyszerűsíteni a problémát, de valójában elképesztően bonyolult gondról van szó, és attól, hogy a bejárás hardveresen gyorsítható, még nem nyertél semmit. Ha nyernénk rajta, akkor a Crytek lenne az első, amely adna rá támogatást, de nem adnak. És ez a lényeges, mert például nekik többet érhet az ExecuteIndirect. Utóbbi ugye dynamic shader raytracingnél nem alkalmazható, miközben jelentős teljesítményelőnye van az olyan típusú motoroknál, amilyen a CryEngine. Tehát ahhoz, hogy nekik legyen natív a DXR 1.0-ra támogatás, ki kell kapcsolniuk az ExecuteIndirectet, és ezzel bukják a vele megnyert 5-20% teljesítményt, konfigurációtól függően. Ergo tökre nem mennek vele semmire, hogy a bejárási lépcsőre vonatkozóan gyorsabbak lesznek, ha végeredményben már lassabb az egész képszámítás. De ugyanúgy megemlíthető még a DXR 1.0 mellett a vertex formátum csak 16 vagy 32 bites lebegőpontos lehet. Az FP16 elég kevés, sok artifactet eredményez, míg az FP32 marhára overkill, mivel egy háromszög 48 bájtos terhelést jelent, ergo, marhára fogja majd zabálni a memóriát. A Crytek megoldásának az is az előnye, hogy kompatibilis a 32 bites snorm formátummal, tehát anélkül tudnak sugárkövetést alkalmazni, hogy az DXR 1.0-es FP32-re való kötelező váltás miatt butítani kellene a geometriát.
Ezek amúgy majd a DXR 1.1-ben meg lesznek oldva, de addig komoly limitációk, és emiatt érdemes az egész képet nézni, mert valójában mindenkinek egy teljes képkockát kell számolni a játékból, ezért nyerhetsz ugyan a bejárási lépcsőn, de ha emiatt buksz egy csomó teljesítményt az FP32 vertex formátummal, illetve az ExecuteIndirect hiányával, akkor hasztalan. Érdemesebb saját megoldással próbálkozni, ahol ugyan a bejárási lépcsőre levetítve a teljesítmény nem olyan gyors, de használható az ExecuteIndirect és a 32 bites snorm vertex formátum.
(#26758) GeryFlash: Mint írtam a CryEngine esetében az a részprobléma, amiről szó van a processzoron lesz kiszámolva, tehát nem a VGA teljesítménye dönt róla. Az, hogy egy hardver mit fog tudni, nehéz megmondani. A PC-s portot a Crysis Remastered esetében a Saber Interactive csinálja. A Crytek a PS4 és Xbox One verzióért felel, míg a Switch verzió fejlesztése közös a Saberrel. Utóbbi elsődlegesen azért lehet, mert a Sabernek sok a tapasztalata a Switch-csel, illetve a PC-s verziót is jó ötlet rájuk bízni, mert a World War Z-nél igen durva optimalizálást tettek le az asztalra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26745
üzenetére
Pont azt írja, hogy nem használnak DXR-t. Amit én is írtam.
Szerintem amúgy pokolian leegyszerűsítitek az egész problémakört, pedig az nem csak a sugarakból áll. Még DXR-nél sem szokás 4K-ban pixelenként sugarat kilőni, mert nem tudsz mit kezdeni velük. Azzal ugyanis, hogy sok a sugár még semmit sem érsz el. A sok sugár ugyanis sok mintavételt eredményez, miközben a legnagyobb problémáját az egész sugárkövetésnek a nem koherens adatelérés jelenti. Tehát nem az számít, hogy ki tudsz-e lőni sokkal több sugarat, hanem az, hogy a hardver képes-e megfelelő időben visszatérni annyi nem koherens mintavétellel, és ez már kizárólag a memória-sávszélességtől függ. Emiatt van az, hogy ma kétféle opció van a sugárkövetésnél. Vagy négy pixelenként számolsz egy sugárral, de maga a sugár hosszabb lehet, vagy egy pixelenként számolsz vele, de rövidebb sugarakkal. A limitet a mintavétel jelenti mindkét esetben, alapvetően a pixelenkénti négy sugár is beleférne a hardveresen gyorsított megvalósításba, csak a mintavétel miatt annyira röviden kellene a sugarakkal számolni, hogy gyakorlatilag alig találnának el valamit. Mert attól, hogy van erre egy fixfunkciós hardvered, még nem biztos, hogy megvan a memória-sávszélességed a probléma megoldásához. És ez az a tényező, ami miatt a Crytek sem a DXR-t választotta, mert a mintavételek tekintetében ugyanazok maradnak a limitek, ugyanúgy gondot fog jelenteni a nem koherens adatelérés, de például sokkal jobb megoldás, ha kevesebb sugarat használsz, és azokat messzebbre lövöd ki, mert mintavételben ez relatíve kellemes, és az adatokkal amúgy is elég sokra lehet menni. Jó példa erre a SEED-féle Pica Pica tesztprojekt, ahol arra a következtetésre jutottak, hogy inkább megéri négy pixelenként sugarat küldeni, majd spatiotemporális szűréssel rekonstruálni az adatokat natív felbontásra. Nem véletlen, hogy ezt csinálja a CryEngine is. Egyszerűen kevesebb sugárból sokkal jobb lesz az eredmény, mert a kevés sugár miatt azok távolabbra mehetnek, és több hasznos információ keletkezik, miközben a hardverek engedte memória-sávszélesség korlátain belül maradsz.Tehát az önmagában igaz, hogy a hardveres gyorsítás több sugarat enged, de amíg nem raksz alá 2-3-4 TB/s-ot, hogy a hardver több sugár mellett is kellő távolságra tudja kezelni a problémát, addig a jelentős limitet a nem koherens adatelérés jelenti, nem pedig a kilőhető sugarak száma. Szóval nem az a kérdés, hogy egy fixfunkciós hardver mit enged meg a sugarak számát tekintve, hanem az, hogy mi az a pont, amikortól a memória-sávszélesség már nem tudja kiszolgálni ezt. És hamarabb jön el az utóbbi limit, mint az, hogy a több sugárnak előnye legyen. Ha nem így lenne, akkor a Crytek is DXR-t használna.
Ha mondjuk idén jönnek az új csúcshardverek 1-2 TB/s közötti sávszéllel, akkor ott már a Crytek is jobban járna a DXR-rel, pláne inline raytracing mellett, mert lenne értelme sok sugarat kilőni, a memóriaalrendszer elég erős ahhoz, hogy a nem koherens adatelérés kevésbé jelentsen limitet. De a mai hardverek azért nincsenek az 1 TB/s közelében sem.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26691
üzenetére
A legnagyobbakon valószínű, hogy nem GDDR6 lesz. Abból nem lehet kihozni 1+ TB/s-ot.
A konzolok itt nem számítanak. Egyrészt ott vannak egyéb tényezők, például sokat kell belőlük gyártani, másrészt a Sony például trükközik, van valami extra hardverjük, amivel hatékonyabb lesz a GPU kihasználhatósága. Továbbra sem érdemes a konzolt és a PC-t hasonlítgatni ezek miatt az apróbb nyalánkságok miatt, ami konzolon működhet, PC-n viszont nem célhardverre fejlesztenek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26677
üzenetére
Az inline raytracing sebességelőnye attól függ, hogy mi lesz a munkamenet. Nem lehet ezt ennyire leegyszerűsíteni, mivel teljesen más kódot igényel.
A másik dolog, amit fontos észben tartani, hogy manapság az RT effektek minőségileg extrém módon vissza vannak fogva. Nem véletlen, hogy sokan azt írják a youtube-on az egyes videókra, hogy a sebesség csökkenésén kívül nem látnak semmit. Ez nem az eljárás hibája, hanem azé, hogy nem lehet szélnek ereszteni a lehetőségeket, mert kevés a hardverek teljesítménye, és a működést biztosító rendszer sem működik hatékonyan. Tehát a következő körben egy RT effekt akár sokkal jobb is lehet a sebességnövekedés miatt, mert el fogják költeni a nagyobb teljesítményt a minőségre, hogy tényleg látni lehessen, ha bekapcsolod. És remélhetőleg el fogják felejteni a kamurobbanásokat is, amivel elrontották a BF5-öt. Ugye ott az a gondjuk, hogy egyszerűen nem számol annyira nagy távolságra a sugárral, így ha a számítási határon kívül esik egy robbanás, akkor az már nem látszik visszatükröződve a felületen. Ezért azt csinálták, hogy néha megtörténik a felületeken egy kamurobbanás, ami viszont a tényleges pályán nem létezik. Na erre oltári jó lesz az inline raytracing, mert például a Microsoft devnapján bemutatott Xbox Series X demón nagyon nagy távolságig el voltak engedve a sugarak, és a felület nem csak a távoli felületet tükrözte vissza, hanem azt is, ami a visszatükrözött felületen belül is vissza volt tükrözve. Persze szerintem ez marhára overkill, de azt ténnyleg mutatja, hogy mennyire hatalmas a fejlődés a dynamic shader raytracinghez képest, ahol kamurobbanásokat kell csinálni, hogy látszódjon a működése. Viszont ezek azért még a szoftveres fejlődéssel sem lesznek ingyen, bizony követelni fogják a hardveres hátteret, elsősorban sebességet.
Szóval a jövőben is nagy teljesítményhátrány lesz a sugárkövetés, mert egyszerűen számításigényes. Az inline raytracing egyszerűen csak megadja azokat a lehetőségeket, hogy az RT effekt minőséget is hordozzon, ne legyen jelentősen limitálva.
A memória-sávszélességre vonatkozó problémán nem tudsz hogyan segíteni. Egyszerűen a másodlagos sugarak nem koherensek. Talán egy hardveres koherenciadetektor előnyös lenne, de az sem olcsó ám a tranyóköltségek szempontjából. Itt a cache sem igazán segít, mert összeszemeteli a feladat. Ha nincs koherenciadetektor, akkor több memória-sávszélesség kell. Az inline raytracing ezen a problémán annyiban javít, hogy a sugárkövetés egy shaderből való megoldása redukálja az adatforgalmat a memória felé, esetenként komolyan, de az alapproblémát magát nem oldja meg, csak valamennyit segít a hardvernek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#26676
Abu85
HÁZIGAZDA
szmörlock007
#26673
Abu85
HÁZIGAZDA
válasz
szmörlock007
#26673
üzenetére
Bizonyosan meglett volna az inline raytracing, de ettől a DXR 1.0 így is előnyös volt, mert hiába rossz a hatásfoka a dynamic shader raytracingnek, akkor is egy rakás tapasztalatot lehetett vele gyűjteni. Az inline raytracing ugyan hatékonyabb, de az effekt dizájnja szempontjából a kérdések ugyanazok, és ez sem egyértelmű ám.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26671
üzenetére
Nem. Ez egy nagy tévedés. Bizonyos munkákat megspórol, de más munkákat megnövel, mert a geometria válik a szűk keresztmetszetté, és így jobban kell majd optimalizálni a modelleket. Nem véletlen az, hogy az RT patchek nem jönnek napokon belül. Nagyon sok munka ezt is megcsinálni, nem optimális modellek mellett még több munka is, mint raszterizációs trükköket alkalmazni. Szóval a sugárkövetés csak egy olyan módszer, amivel bizonyos trükkös megoldások kiválthatók, de nem automatikusan olcsóbb, csak máshova költöd majd a pénzt. És ugyanúgy lesz vele munka bőven, egyáltalán nem "just works" jellegű a dolog. Ha az lenne, akkor nem patchben jönnének az effektek a játékok zöméhez.
A Microsoft számára természetesen jó volt egy nulladik generációs irány. Csinálták a sajátjukat a háttérben, és azért a fejlesztők is tapasztalatot szereztek ezzel. Pár játékban azt is meg lehet mutatni, hogy mit nem szabad csinálni. Ez nulladik generáció nélkül nem lenne, és ezekbe a csapdákba most esnének majd bele a fejlesztők. Nyilván nem lenne jobb a helyzetünk.
A Crytek megoldása a processzoron fut, tehát a gyorsítóstruktúra generálása ugyanolyan gyors lesz, akármilyen VGA mellett, feltéve ha van elég gyors processzor hozzá. A host CPU-ra való kihelyezés egyébként a Vulkan API-nak is a része lesz, így tehermentesíteni lehet a GPU-kat. Persze a CryEngine az tényleg erre szabott motor, itt előnyben vannak. Ami biztos, hogy ugyanolyan processzor mellett mindegyik VGA ugyanolyan gyorsan dolgozik majd a gyorsítóstruktúrával. A többi már a shaderektől függ, amik majd a multiprocesszorokon futnak.
Az Ampere sokkal gyorsabb lesz. Korábban írtam, hogy maga a DXR 1.1 az, ami jelentős gyorsítást jelent. Ha ezt kezeli a hardver, akkor állva tud hagyni bármi korábbi generációs terméket. Mindemellett azért tudni kell azt is, hogy az új generációs GPU-k egyik fő újítása, hogy igazi cache szörnyetegek lesznek. Egységnyi ALU-ra, sokkal, de sokkal több cache fog jutni. Ez óriási segítség a komplex shadereknél, amelyek mondjuk a kevés LDS és cache miatt nem tudnak kellő mennyiségű wave-et indítani. Ég és föld lesz ilyenkor a különbség még ugyanannyi ALU mellett is.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#26670
Abu85
HÁZIGAZDA
szmörlock007
#26667
Abu85
HÁZIGAZDA
válasz
szmörlock007
#26667
üzenetére
Pontosan nem tudni, de a Microsoft a DXR 1.1-et már támogatni fogja. A DXR 1.0-t azért hanyagolták, mert nem ők tervezték. Nem is foglalkoztak igazából a támogatásával. Ezért alakulhatott ki az a furcsaság, hogy a Microsoft hozott egy API-t, de külső fejlesztők hozzák a játékokat rá.
(#26669) Jacek:
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#26665
Abu85
HÁZIGAZDA
szmörlock007
#26664
Abu85
HÁZIGAZDA
válasz
szmörlock007
#26664
üzenetére
Ezt írtam, jól értelmezed.
Csak a Tiger Lake-ről van pár adat, de nem ugyanazt a dizájnt kapja a dedikált GPU. Eléggé hasonló amúgy a felépítése a mostani dizájnokhoz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mindenképpen a legújabb hardverekből vegyél, ha maximalista vagy. Amik most vannak azok nem túl jó vételek az új lehetőségek szempontjából. Meg ha már eddig kibírtad, akkor...
(#26662) b. : Attól, hogy az inline raytracinghez új hardverek kellenek, még nem lesznek kukák a mostaniak. Maximum azoknak, akik nagyon maximalisták. Viszont xy effektet ki is lehet kapcsolni például. Nem kell azokat megjeleníttetni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem akarlak elkeseríteni, de nem az ész fogja meghatározni a váltást. Amiért az inline raytracing felmerült az az, hogy még az elején járunk az egésznek, tehát az volt a kérdés, hogy megéri-e most jelentősen belenyúlni a működésbe, és felkínálni egy sokkal gyorsabb alternatívát. A legtöbben erre azt mondják, hogy megéri, mert a legtöbben úgysem váltottak új hardverre, annyira nem volt sikeres a DXR marketingje, tehát ha valamikor, akkor most még megéri a reset. Egy körrel később már sokkal nehezebb lenne, mert sokkal több hardver lenne a felhasználóknál, amiket igenis támogatni kellene.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem egészen, de majd meglátod, ha közelebb kerülünk az új GeForce megjelenéséhez. Ne éld bele magad, mert csalódni fogsz. Egy hardvert nem tudnak felokosítani, nem véletlenül olyan a DXR 1.0, amilyen, és nem véletlenül csak most jön az inline raytracing, ami egy elég nagy váltást képvisel. Leírtam fentebb, hogy nehéz lesz a nem felkészített hardvereknek kiválasztani találomra azt a memóriacímet, amire pont szükségük van, mert bekötési táblájuk a DXR 1.1-ben nem lesz hozzá. Egy a sokmilliárdhoz az esélye, hogy sikerülni fog.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az a táblázat arra vonatkozik, hogy a Turingra és az RDNA2-re létezik DXR 1.1-es implementáció. Az Xe azért van kérdőjellel, mert ahhoz még abban az időben nem készített implementációt az Intel. Egyébként mára már készített. Az implementáció viszont a támogatásra vonatkozik csak, lásd a Pascal is rendelkezik DXR 1.0-s implementációval.
A Microsoft egészen konkrétan azt mondta, hogy az új generációs termékek hardveresen is támogatni fogják a DXR 1.1-et, külön kiemelték az inline raytracinget. De architektúraspecifikusan nem mentek a részletekbe, azt is elmondták, hogy ez nem az ő feladatuk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Természetesen nehéz lesz egy hardvernek lekövetnie a teljes sugárkövetést, ha egyszerűen nem erre tervezték. Olyan ez, mint a 2000-es években a transzformáció és megvilágítás forradalma. Előbb kaptunk T&L-t, ahhoz új hardverek kellettek, majd nem sokkal később jött az alapszintű programozhatóság, megint új hardverek igényével, és így tovább. Most megint van valami újdonság, ami ráadásul fixfunkciós blokkokra épít, és amint van valami kicsit is nagyobb újítás az API-ban, rögtön kellenek hozzá az új hardverek. Egy pár év, és ugyanúgy be fog ez állni, mint anno a programozható shading, de amíg csak gyerekcipőben tipegünk, addig 2000-es évek eleje lesz megint, ahogy jön új DXR, kell majd hozzá az új hardver.
A nagy kérdés az, hogy a játékok csak inline raytracinget fognak tartalmazni, vagy lesz egy port a dynamic shader raytracingre is. Utóbbit tudja támogatni a Turing, hiszen erre tervezték. De az inline raytracingben nincsen bekötési tábla, nem tudja a hardver végigkövetni a teljes feladatot, ki kell írni a részeredményeket, de mivel a fejlesztők nem írnak külön shadereket, így nem is írják meg a hardvernek, hogy mit hova írjon ki, és melyik shadernek mire van szüksége. Márpedig a hardverek ugyan sok dologra képesek, de kismillió memóriacímből nem tudják találomra kiválasztani, hogy melyik kell éppen, ha nem mondja meg nekik a program. Ezért kell az inline raytracinghez lényegesen combosabb ütemező, hogy ne szoruljon rá a hardver a szoftveroldali segítségre. Ha csak ezt támogatja egy új alkalmazás, akkor új hardver nélkül nem sokra mész. De ha kap még dynamic shader raytracing módot is, akkor működhetnek a Turing fixfunkciós blokkjai. Ez pedig már a fejlesztőktől függ, hogy ugyanazt az eljárást egyszer, vagy kétszer írják meg.
(#26652) Segal: Ha csak inline raytracinget fog támogatni a program, akkor az nem jó a Turingnak. Ahhoz új hardver kell mindenképpen a jó sebességhez. A dynamic shader raytracing viszont jó a Turingnak is, csak ez lassabb, mint az inline raytracing.
Sajnos hivatalosan a Microsoft nem mondhatja el, hogy mit támogatnak az új architektúrák, de egyértelműen utaltak rá, hogy a következő generációban mindenkinek lesz DXR 1.1-hez tervezett hardvere.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért, mert a szoftver a processzoron fut, ha nem vetted volna észre a CryEngine-nek ezt a működését.
Ahhoz, hogy mondjuk ebből legyen egy hardveres gyorsítás egyrészt támogatni kellene a DXR-t, amivel elvesztené a Crytek a hardver- és API-függetlenséget, másrészt ugye azért ment a Crytek a szoftveres irányba, mert a motorjukban ez a gyorsabb. Tehát nem fognak ezen lassítani csak azért, hogy hardveres megoldást használjanak. Te se kapcsolnád be csak azért, mert hardveres. A végeredményben a sebesség számít, és a Crytek gyorsabban megcsinálja a DXR 1.0-nál, tehát számukra utóbbinak nincs értelme. Pénz lenne rá, de sebességcsökkentésre nem szokás költeni.
Alapvetően a működésről beszélünk. A Microsoft sosem mondta, hogy jó sebessége lesz a DXR 1.0 a nem erre tervezett hardvereken. A DXR 1.1 esetében is így lesz. Ott is csak az ehhez tervezett hardvereken lesz jó sebesség, de ettől függetlenül működőképes lehet bármilyen compute shadert támogató GPU-n.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ha szoftveres az RT, akkor nem tud hozzányúlni a fixfunkciós hardverekhez, ezért szoftveres.
A DXR 1.1 inline raytracingje nem a mai hardverekre készült. Ne várjatok csodát, mert csalódni fogtok. Ezt meg kellett lépni a Microsoftnak a jövő érdekében, mert még az elején vagyunk, és egy restart most nem jelent nagy kárt a piacnak. Nem mellesleg szoftveresen ugyanúgy írható mindenre támogatás, ahogy a DXR 1.0 esetében. Így működik a Pascalon is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26644
üzenetére
A hozzászólás elején írtam, hogy a DXR 1.0-hoz hasonlóan a DXR 1.1 is lehetővé teszi, hogy compute shaderből megoldják a gyártók. Lásd a Pascal is megoldja a DXR 1.0-t, pedig nincs benne célhardver. Ugyanígy megírható compute shaderben a Turingra is a DXR 1.1... sőt, akármelyik, compute shadert minimum támogató GPU-ra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26642
üzenetére
Nem. Ahogy a DXR 1.0, úgy a DXR 1.1 is megengedi azt, hogy a nem támogatott funkciókat compute shaderrel helyettesítsd. Akár az egész futószalag használhat compute shadert. Tehát mindenre lehet DXR 1.1-hez támogatást írni, ahogy a Pascalra is lehetett DXR 1.0-hoz. Az alapvető követelmény pusztán egy olyan hardver, ami compute shadert támogat, illetve egy olyan meghajtó, amelynek a fordítója DXIL IR-t elfogad.
Ugyanakkor maga az inline raytracing egészen máshogy működik, mint a dynamic shader raytracing, így olyan követelményei vannak, amik új tervezésű hardvereket igényelnek.A Microsoft elmondása szerint két alapvető fontosságú igény lesz az inline raytracinggel az architektúrák felé, ha a futószalag minden gyorsítást támogató lépcsőjét fixfunkciós hardverrel szeretné kezelni a rendszer. Egyrészt tudni kell a hardver ütemezőjének kezelni azt a kontextusstruktúrát, amivel egy shaderben leírható, hogy hit esetén térjen vissza az eredménnyel, és annak megfelelően a kontextusstruktúra minden szükséges adattal rendelkezzen. Az adatmozgatást tehát az inline raytracingnél gyakorlatilag fű alatt csinálja a rendszer, nem kell foglalkoznia a programozóknak azzal a problémával, hogy melyik shadernek milyen adatokat biztosítsanak, mert maga a hardver gondoskodni fog arról, hogy minden ott legyen egy helyen. Ennek ugye az a rákfenéje, hogy eléggé bonyolult ütemezést igényel, mert gyakorlatilag a teljesen végig kell követni egy sugár útját, nincs lehetőség arra, hogy külön shader gondoskodjon a sugár indításáról, nem lesz egy bekötési tábla a memóriában, amibe lehet írni a részadatokat, nem fog külön shader futni a hitre és a missre, stb., tehát programozói szempontból a probléma jelentősen egyszerűsödik, de sokkal combosabb hardver is kell, ami egyben meg tudja oldani azt, amire eddig külön a program oldaláról kellett apránként utasítani a hardvereket. A másik igény ebből a változásból ered. Mivel eddig a részfeladatok egymás után sorban lettek végrehajtva, így nem volt követelmény az, hogy mindegyik futószalaglépcső ugyanahhoz a hardverállapothoz kötődjön. Az inline raytracing esetében ez az, hiszen egyetlen egy compute shaderre le lehet szűkíteni a problémát, tehát okvetlenül fontos, hogy a fixfunkciós egységek elérhetők legyenek ugyanabban a hardverállapotban, mint amiben a compute shader. Sőt, a DXR 1.1 további változásai mellett, például, hogy akármilyen shader lépcsőből elérhető az inline raytracing, az a legjobb a hardver tekintetében, ha a compute shader, illetve a gyorsítást végző fixfunkciós egységes stateless módban működnek. Ezt persze rohadt nehéz megcsinálni, könnyű ilyet mondani, csak ugye a gyakorlat...
Nem véletlen, hogy a GCN-en és az RDNA-n kívül nincs olyan hardver a piacon, ami a compute shadert stateless futtatja. Túl nagy tranzisztorbüdzséből oldható csak meg, és a valós előnye kimerül az aszinkron compute-nál, ami a mai játékokban úgyis döntő részben pixel shaderekkel fut párhuzamosan, tehát egyszerűbb az a megoldás, amit az NV csinál a Turingnál, hogy a compute és a pixel shader hardverállapota azonos. A valós programokban mutatott gyakorlati eredmény ugyanaz, miközben sokkal kevesebb tranzisztort kellett a megvalósításhoz elhasználni. A DXR 1.1 már egy kicsit keményebb duó, így át kell értékelni a hardvertervezést, mert szar dolog lesz sűrűn állapotot váltani, az azért durva lassulással jár. Tehát itt már a stateless mód erőltetése több hardveres részegységre, illetve feldolgozási formára valóban kézzel fogható előnyöket hoz, nem csak elméletit. Plusz az is számít, hogy az új generációs hardvereket már új node-okon tervezik, tehát tranzisztorbüdzsé is van a változtatásokra.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Már bejelentették az igazságot:
Crysis Remastered will feature the original game’s single-player campaign alongside high-quality textures, an HD texture pack, improved art assets, temporal anti-aliasing, SSDO, SVOGI, state-of-the-art depth fields, new light settings, motion blur, parallax occlusion mapping, and particle effects (where applicable). Further additions like volumetric fog and shafts of light, software-based ray tracing, and screen space reflections deliver a major visual upgrade to this classic FPS experience.
(#26636) GeryFlash: Nem pár effekt miatt drága a játékok fejlesztési költsége. Ha mondjuk az a két-három effekt, amit alkalmaznak olyan drága lenne, hogy befolyást jelentene a végső árra, akkor az történne, hogy le se fejlesztenék. De valójában ezeknek az effekteknek a valós költsége eltörpül a teljes fejlesztés anyagi követelményei mellett.
A DXR 1.0-nak azzal vége is, hogy a DXR 1.1-ben jön az inline raytracing, tehát a mostani dynamic shader raytracing gyakorlatilag halott, az erre tervezett hardvereknek pedig kampó. Kellenek az inline raytracingre tervezett új hardverek, tehát a terjedést a nulláról újra kell kezdeni. Semmit nem nyertünk végül ezzel az időszakkal, csak csináltunk egy zsákutcát, amire a Microsoft csinált is gyorsan egy sokkal jobban működő alternatívát.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#26631
üzenetére
Egy túrót. A sugárkövetésnek vajmi kevés köze lesz ehhez. Tényleg azt hiszitek, hogy egy játék fejlesztési költségét az a két-három effekt dobja meg, amit majd megcsinálhatnak sugárkövetéssel. Ha így lenne, akkor eleve kivennék ezeket a szuperdrága grafikai effekteket, és aranyakor jönne.
Jól hangzik a marketinges "just works" duma, de ha ez tényleg csak just works lenne, akkor nem kellett volna több játéknál is heteket-hónapokat várni az RT patch-re.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A távolabbi jövőben szerintem mindenki inline raytracinget fog használni. Az tűnik jelenleg messze a legjobbnak. A mostani dynamic shader raytracing nem elég gyors, és nem véletlen, hogy nem csak a Crytek nem akarta használni, hanem volt itt még a Wargaming, illetve a Gaijin is, amelyek szintén saját megoldást fejlesztettek. Nagyon is gyorsat úgy, hogy hozzá sem nyúltak a a fixfunkciós hardverekhez.
Ahogy viszont fentebb írtam, az inline raytracinghez új hardverek kellenek. Tehát értem azt, hogy a Microsoft miért cserélte le a jelenlegi, abszolút nem hatékony dynamic shader raytracinget, csak ezzel ugye az erre tervezett hardvereknek is kampó.
Sehol sem írtam, hogy a dedikált hardver hülyeség. Azt írtam, hogy az a működés hülyeség, hogy külön shaderek futnak egymás után részfeladatokkal, mert meg lehetne oldani ezt egyetlen shaderből is, és akkor sokkal gyorsabb lenne a feldolgozás. És a DXR 1.1 pont ezt hozza az inline raytracinggel. Tehát maga a Microsoft is hülyeségnek látta a korábbi modellt, ha nem lenne az, akkor nem hoztak volna rá egy sokkal gyorsabb alternatívát. Így már viszont elég sok értelme van a dedikált hardvernek, mert az inline raytracinggel nem kell benyalnod azt a sok, hardverek rossz kihasználáshoz vezető lassító tényezőt, amire a dynamic shader raytracing ma rákényszerít. Jó dolog tehát a dedikált hardver, ha nem kényszerít rá, hogy leharapjam a másik kezem. Így már valószínűleg tetszeni fog például a Cryteknek is, mert gyorsabb kódot is tudnak írni a saját megvalósításuknál.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mint írtam, semmi különleges nem történik itt. Az NV csak a Turingra írt egy drivert, de ennyi. Az AMD is megteheti, kicserélik a shadereket, de annyi erőforrást elvisz, hogy felesleges egy demó miatt megtenni. A Pascal is sokkal gyorsabb lenne, ha az is kapott volna optimalizálást. Pont az volt a lényege az NV driverének, hogy azt hidd, hogy a Turing ennyire fasza RT-ben, és semmiképpen se lásd meg, hogy a Pascal is tudná azt a sebességet. Eléggé kivégezte volna az NV kommunikációját, mert visszakérdeznél, hogy akkor mi értelme a dedikált hardvernek. Viszont ezzel egy csomóan bekajálták, hogy biztos használja a program a fixfunkciós hardvereket, pedig nem ez az igazság, de a lényeg, hogy elhiggyék az emberek a kapitális faszságot.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
"To get right to the heart of it, this demo utilises DirectX 11 and requires no specific ray tracing hardware" - [link]
Az 5.5 és az 5.7 az engine-re vonatkozik, csak lemaradt a copy-paste-tolt szövegből. A demó maga az 5.5-re készült.
A demónak mások a követelményei. Ezek itt olvashatók: [link] - itt is DX11 van megjelölve.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#26624
Abu85
HÁZIGAZDA
huskydog17
#26621
Abu85
HÁZIGAZDA
válasz
huskydog17
#26621
üzenetére
Részben igaz, ugyanakkor számít még a driver is.
Viszont manapság, ha egy GPU modern dizájnt használ, értsd úgy, hogy legalább nem emulál a CPU-n keresztül semmit a bekötés szempontjából, és a D3D12 implementációja is eléggé kiforrott, akkor ma már a D3D11-nél gyorsabb szokott lenni.A user igazából sosem hunyó. Vagy a hardver nem elég modern, vagy a meghajtó nem elég kiforrott, vagy mindkettő, vagy a programban van valami gond, de manapság az utóbbi már nem jellemző. Maximum akkor, ha a program az új API-t valami specifikus probléma megoldására használja.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem érted amit írtam. Ragaszkodsz valamihez, amiről maga a fejlesztője jelentette ki, hogy nem úgy van. De ha nem hiszel a fejlesztőknek, akkor csak a saját józan eszed használd, és gondolj bele, hogy a DirectX 11-ben ugyan hogyan lehetne egy shader model 6.0-t minimum követelő modult meghívni. Maga a shader modell 6.0 nem is engedi a fordítást a D3BC IR-re, tehát, maga a DirectX 11 API használata teljesen kizárja, hogy hozzányúljon olyan hardverelemekhez, amelyek nincsenek is definiálva az API-ban. Tehát ha nem hiszel sem nekem, sem a fejlesztőknek, sem a Microsoftnak, akkor is ott a logika, amivel kikövetkeztethető, hogy ez a demó egyszerűen nem tud hozzányúlni azokhoz a fixfunkciós hardverekhez. Nem látja őket, mert nem használja a legújabb API-t, amivel ezek elérhetők.
A másik dolog, hogy a Crytek elsődlegesen azért használ saját megoldást a problémára, mert a DXR 1.0-s opciónál tudnak gyorsabbat csinálni. Attól, hogy valamit fixfunkciós hardver csinál meg, még nem lesz gyors. A fixfunkciós hardver előnye ugyanis tart az adott feladatig, de a gyorsítóstruktúra a sugárkövetésnek egy szelete csak, és ha arra kényszerít téged az API-ban lévő futószalag, hogy külön shader feleljen magának a sugárnak az indításáért, külön shader fusson hit vagy miss esetén, és ezektől függően külön shader induljon a bejárás eredményére építve, az mond rontja a feldolgozás oroszlánrészének a hatákonyságát. Tehát sebességet nyertél a fixfunkciós hardver miatt a teljes feladat egy részében, de ezt kamatostul elveszíted a maradék munkán. És ez az, amit a Crytek el akart kerülni, mert nagyok ám a DXR 1.0 limitációi, nem véletlenül nyúlt bele olyan elképesztő mértékben a Microsoft, hogy a DXR 1.1-ben hoztak egy teljesen alternatív megoldást a sugárkövetésre. Ők is érezték, hogy szart sem ér a hardveres gyorsítás, ha a limitációk miatt kamatostul elveszíted a megnyert sebességet.
Tehát a Crytek elméletben használhat DXR 1.0-t, de minek. A mostani megoldásuk gyorsabb, csak lelassítanák a Turingot vele. A DXR 1.1 már értékes megoldás, mert a működés tekintetében hasonlít ahhoz, amit éppen most csinálnak, és ebből már valós sebességelőnyt is tudnának szerezni, de ehhez kellenek a legújabb hardverek, amik még nem is érhetők el. Anélkül a DXR 1.1 nem igazán fog működni. És innen nincs nagy haszna gyökeresen átírni a saját megoldásukat, mert a sebessége annak is nagyon jó, és eközben még arra sem kényszeríti a felhasználókat, hogy RDNA2-t vagy Ampere-t vegyenek. Nem mellesleg teljesen kompatibilis az Xbox One és PS4 konzolokkal, illetve még a Switch-csel is.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
És ki dönti el, hogy használ-e fixfunkciós hardvert? Mert te annak ellenére sem vagy hajlandó elfogadni, hogy a Neon Noir nem használ, hogy 1. hivatalosan bejelentették, 2. DirectX 11-ben elérhetetlenek ezek a célhardverek, 3. processzorral csinálják meg a gyorsítóstruktúrát.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem tudja támogatni. Nem úgy működik. Eleve DirectX 11-et használ, ahol nincs is shader modell 6, ami a DXR alapfeltétele, illetve a processzor csinálja meg ezt a feladatot. Nem lehet csak úgy átrakni, mert azzal elveszti a legnagyobb előnyét, vagyis a hardver- és az API-függetlenséget. Nem mellesleg a Cryteknek felesleges is lenne támogatni, mert gyorsabb a megoldásuk a fixfunkciós hardverek nélkül, ugyanis egy csomó DXR limitációt szoftveresen ki tudnak kerülni, ami sokat lassít ám a hardvereken, de ezt a CryEngine nem nyeli be. Egyedül az inline raytracingnek lenne értelme a szemükben, de azt meg normális sebességgel csak az érkező hardverek fogják támogatni. A többi nem, nem úgy tervezték az ütemezőjüket, hogy egy szimpla kontextusstruktúra alapján visszatérjen egy hittel. A DXR 1.1 ezt megköveteli a hardvertől, és ehhez nagyon is át kell tervezni a dizájnokat. Ha most szimplán a DXR 1.0-ra dolgoznának, akkor csak sebességet vesztenének, miközben egy rakás kódot át kellene írni, és elvesztenék a hardver- és API-függetlenséget is.
Azt nem tartom kizárnak egyébként, hogy az inline raytracingre rácuppannak, de nem azonnal, mert előbb meg kell várni, hogy a még nem elérhető GeForce-ok és Radeonok terjedjenek. Ezek nélkül ugyanis nem sok haszna van az inline raytracingnek.
Persze. Mint írtam nem nagyon foglalkoznak csak egy demó kedvéért a driverrel. Hiába jobb hardver a Radeon 7, mint a Vega 64, sokat számít, hogy milyen optimalizálásokat kap a meghajtó oldaláról. De egy demó érdekében felesleges leültetni egy csapatot, hogy elkezdjék kicserélgetni a shadereket, ráadásul hardverspecifikusan.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A tensor magok nem olyan egyszerűek ám. Elég sok helyet is igényelnek.
A hardver szintjén azért bonyolultabb az RT, mint a raszterizáció. Nem a fixfunkciós részegység teszi azzá, hanem a feladat komplexitása, illetve a koherencia részleges hiánya.
A gyorsítóstruktúra nem akkora probléma. Látható, hogy többet megoldották fixfunkciós hardver nélkül, csak a jó működéshez igen speciálisan felépített motor kell, lásd CryEngine. A legtöbb motor nem ilyen.
Mondjuk ezek a sugárkövetéstől sem lesznek. Más problémák limitálják a fizikai szimulációt.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#26610
üzenetére
Mint írtam már láthatod. Kiadták már a Neon Noir demót. Abban a Crytek úgy csinálja a sugárkövetést, hogy hozzá sem nyúl a fixfunkciós részegységekhez. És eközben a sebesség kiemelkedően jó. Az valószínű, hogy az inline raytracing sebességét nem fogják verni, de ahhoz meg új hardverek kellenek, tehát még így is előnyös a megoldásuk.
Mindegy, hogy mire készült. A lényeg, hogy működik. Egy játékban is ugyanígy fog működni. Persze gondolom még optimalizálnak rajta, mert kezdetleges a kód, de ez természetes.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#26607
üzenetére
Azzal dobják ki. Írják, hogy a sahát sugárkövetéses megoldásukat használják. Nekik felesleges a DXR, mert gyorsabb a saját technológiájuk. Talán az inline raytracinggel lehetne kezdeniük valamit, de gondolom nem akarnak olyan játékot kiadni, ahol az egyes effektek nem futnak jól a most elérhető hardvereken.
Nincs mire, megmutatták már a saját demójukat, hogy mennyire gyors, és nulla fixfunkciós hardvert használ. Nekik egyszerű, mert eleve voxelizálnak a motorban, tehát van egy olyan funkciójuk, ami a legtöbb motorból hiányzik, és erre építhetnek.
Az a baj, hogy az emberek csodát várnak attól, hogy a sugárkövetés hardveresen van gyorsítva, eközben pedig csak limitációkat jelent jelenleg. Igen, az inline raytracinggel ezeket kezeli a Microsoft, de ez nem fut jól a most elérhető hardvereken. Kellenek hozzá a legújabb, év végén érkező architektúrák.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dyingsoul
#26604
üzenetére
Azt mondjuk hozzá kell tenni, hogy a DXR 1.0 eléggé fos megvalósítást alkalmaz RT-re. Nem véletlen, hogy a CryEngine célhardvereket nem is használó megoldása agyonveri. Egyszerűen maga a szoftveres háttér fos az aktuális DirectX-ben, ami olyan elképesztően rossz hatékonyságra kényszeríti a hardvert a shaderek soros végrehajtásával, hogy roppant gyenge lesz a sebesség.
Tehát lehet mondani, hogy most nem éri meg a felárat az RT, mert ez abszolút igaz, de maga a DirectX Raytracing aktuális verziója nem működik úgy, hogy gyors lehessen a feldolgozás. A hardver ehhez keveset tud hozzá tenni, elfogadja, hogy szép sorban kell feldolgoznia a shadereket, még ha lesz vele egy rakás üres ciklusa is.Nem véletlen, hogy a Microsoft a DXR 1.1-ben pont ezen változtat, és behozza azt a feldolgozási formát, aminél egyetlen egy shaderből is megoldható maga a feladat, így ugyanazt a munkát nagyságrendekkel hatékonyabban tudja elvégezni a hardver. Szóval amit most látsz az valóban rendkívül gyenge, de a DXR 1.1 pusztán a specifikációban végzett módosítások miatt lényegesen többet fog kínálni, és eközben lényegesen kevésbé fogja zabálni a sebességet.
Eredetileg egyébként a DirectX Raytracing a DirectX 12 Ultimate-tel érkezett volna, csak az NV ragaszkodott egy nulladik generációs verzióhoz, viszont azt a fenti limitációkkal kellett megírni, és emiatt sajnos külön shader felel magának a sugárnak az indításáért, külön shader fut hit vagy miss esetén, és ezektől függően külön shader indul a bejárás eredményére építve. Ez mind azért probléma, mert minden egyes shader csak egymás után futhat le, ugyanis egymás eredményére várnak, és meg kell oldani az adatok megosztását is, hiszen effektíve egymás eredményeivel számolnak tovább. Már ez a futószalag nagyon rossz hatékonysággal működteti a hardvereket, mert egyrészt a függőség akadályozza az optimális, adatpárhuzamos végrehajtást, másrészt, ha nincs valami trükkös módra lehetőség az adatok átadása szempontjából, akkor minden shader kiírja a memóriába, majd a következő shader beolvassa, vagyis egy rakás üresjárat lesz a hardveren, amíg az adatok beérkeznek.
Az inline raytracing lett volna a kezdeti modell, ami elég komoly ütemezőt igényel a hardverben, illetve meg kell oldani, hogy az egész munkamenet, amivel a sugárkövetés jár, egy hardverállapotból legyen elvégezhető. A legjobb egy stateless megoldás, vagyis az, ha a hardver a compute shader futtatására, illetve a bejárási feladatokra nem is igényel speciális hardverállapotot. A Turing nem ilyen hardver, tehát az inline raytracinget nem tudták PC-re az elején bevezetni, de a következő GeForce architektúra már ilyen hardver lesz, meg a konzolok is, illetve az RDNA2 is. Az inline raytracing pedig ugyanúgy emulálható a compute shadert támogató hardvereken, tehát a Turingra lehet írni szoftveres támogatást rá, a Pascalra is, akármire, ami compute shadert támogat.
Tehát az ne vegye el senkinek a kedvét, hogy most nem látja, hogy működik-e az RT, mert nem látványos a változás. Ez azért van, mert már maga a szoftveres háttér rosszul van kidolgozva, és az egész programfuttatás egy rendkívül limitált hardveres működésre van kényszerítve, de a következő kör az jó lesz, mert a DXR 1.1 pont a hibákra reflektál. Szép új hardvereket is kap, ami drámai mértékben javít a feldolgozás hatékonyságán.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dyingsoul
#26586
üzenetére
Mint írtam az RE3-ban nem éppen a teljesítmény miatt van a DirectX 12. A jobb memóriamenedzsment a lényeg, mert a játék motorja úgy működik, hogy a textúrarészletesség nem állandó. Amit beállítasz, az csak egy elérhető maximum, de ha nincs elég VRAM kapacitásod rá, akkor elkezdi csökkenteni a textúrák részletességét, így az új felületekre már nem kapsz teljes részletességet, annak ellenére, hogy ezt kiválasztottad. A DirectX 12 ezt úgy kezeli, hogy nagyon hatékonyan defragmentálja a VRAM-ot, elég olcsón is töröl belőle allokácót, tehát mondjuk maximális részletességű beállítás mellett jó esélyed van arra, hogy a VRAM-ból való kifogyás határán legalább közepes részletességű textúrát kapj, míg DirectX 11-ben inkább alacsony részletességet fogsz kapni. Maga a probléma mindkét API-n kezelhető, de DirectX 12-vel sokkal hatékonyabban, így jobban fog működni a streaming. Ez alapvetően valós előny.
Az, hogy a DirectX 12-ben a GeForce 5-7%-nyira van a DirectX 11 teljesítményétől leginkább abból ered, hogy a Capcom az AMD memóriamenedzsmentre vonatkozó middleware-jét használják a DirectX 12 API-hoz, és ebben nincs optimalizálás GeForce-ra. De lehetne, az NV nekiülhet nyugodtan, nyílt forráskódú megoldásról van szó. Írtam azt is, hogy az Intel írt bele optimalizálást magukra, nem probléma, ez a lényege a nyílt forráskódnak.A fentiek mellett azt megjegyezném, hogy az AMD-nek a VMA-ja és a D3D12MA-ja nem igazán teljesítménycentrikus megoldás. Eléggé általános függvénykönyvtáraknak tekinthetők, tehát úgy vannak felépítve, hogy nagymértékű kompatibilitást biztosítsanak az egyes motorokkal, de valójában azon kívül nem tudnak semmit, hogy működnek. Ergo gyorsabb, ha valaki saját memóriamenedzsmentet ír. Csak ugye az nehezebb is, és sok fejlesztő inkább választja a copy-paste-ot. Már csak azért is, mert annyira nem egyszerű ez a probléma, hogy sokszor a nem is teljesítménycentrikusra szabott VMA/D3D12MA is jobb sebességet ad. Ebben egyébként nagy szerepe van annak, hogy még mindig nincs olyan fejlesztőeszköz, amely pontosan megmutatná, hogy az adott memóriamenedzsment esetlegesen rossz hatékonysága miből ered.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem írtam, hogy kell. Azt írtam, hogy ha akarják azt a plusz nagyjából 5%-nyi teljesítményt, amit ki lehet még hozni, akkor írhatnak ők is optimalizálást a D3D12MA-ban, ahogy az Intel teszi például. Az AMD beolvasztja a kódot, de ők maguk nem költenek erőforrást a konkurens hardverekre való optimalizálásra, a fejlesztők pedig láthatóan nem érdekeltek ebben, mert elég sok kódból áll ez az általánosra tervezett D3D12MA middleware. Nekik a copy-paste elég jó. De ha az NV is kapna optimalizálást, akkor ugyanúgy közel lenne nekik is a teljesítményük a D3D11-hez az RE3-ban.
A Pascal hátránya akkor jön ki, ha egy játék épít a resources heap TIER_2-es szintjére. Például az RDR2 ilyen. De egy DirectX 11-et is kezelő programon belül ezt maximum támogatni lehet, de lényegesen építeni az előnyeire nem. Ehhez el kell szakadni a DirectX 11-től.
Az RE3-ban a DX12 azért van benne, mert ugyanakkora VRAM kapacitásba több jobb minőségű textúrát tud betölteni ezzel az API-val.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#26579
üzenetére
Csinálhatsz valódi szintlépést is. Vannak ilyen játékok. Ezekből a legacy API már ki is van véve. Például az RDR 2. A probléma itt abból ered, hogy nagyon sok, igen régi tervezésű architektúrának ez nem fekszik, még a Pascal is maga alatt teljesít rendesen, pedig nem olyan régi ez a dizájn. Szóval nehéz az ilyen döntéseket meghozni, mert effektíve Turingra, GCN-re és RDNA-ra korlátozott a hatékony programfuttatást.
(#26580) b. : Resident Evil motorja elég sokban különbözik legacy és explicit API-val. Főleg a harmadik részé, ami a második rész memóriamenedzsmentjéről átállt a D3D12MA-ra. Ezt egészítették ki defragmentálással. Emiatt abban mindenképpen előnyösebb már az RE3 DX12 módja, hogy ugyanolyan kapacitású VRAM-nál jobb minőségű textúrákat tud biztosítani, mert ugye magából a defragmentálásból eredően időnként eltünteti a memóriatöredezettséget, amire DX11 alatt nincs gyógyír. A Radeon pedig azért tud közel lenni a DX11-hez, mert maga a memóriamenedzsment, amit a játék használ egy az egyben az a kód, amit az AMD biztosít a D3D12MA-ban. Nulla optimalizálás van benne GeForce-ra, mert az AMD csak a saját hardvereivel foglalkozik. Viszont az RE3 fejlesztői mondták az AMD-s briefingen, hogy maga a megkapott kód elég jól működik GeForce-on is, ha optimalizálnának rajta lehet, hogy lenne benne +5%, de nagyon sok munkával járna. Az NVIDIA viszont ezt a munkát vállalhatná, mert maga a D3D12MA nyílt forráskódú. Az Intel például ír bele optimalizálásokat a saját hardvereire, amiket az AMD be is szokott olvasztani a fő branchbe.
Viszont a D3D12MA defragmentálásból származó előnye mindegyik hardveren jelen van. Egyszerűen több a beállítottal megegyező vagy beállítotthoz közeli minőségű textúra fér általa a VRAM-ba. Jóval kevesebbszer fog előfordulni az a helyzet, hogy hiába választod ki mondjuk a magas textúrarészletességet, a memória kapacitásából eredően már csak a low részletesség fér bele az egyes textúráknál. Nincs több hely. A D3D12MA, viszont nagyon hatékonyan tud helyet felszabadítani, anélkül, hogy akadások lennének a játékmenetben. Ez DX11 alatt, pusztán az API működéséből eredően nem lehetséges.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#26574
üzenetére
Van sebességnövekedés, csak olyan architektúrát kell alá raknod, amivel működnek az explicit API-k. Az nem baj, hogy neked jó DX11-ben, de az baj, hogy általánosítasz abból, hogy egy csomó funkciót emuláló architektúránál nincs sebességnövekedésed explicit API-val. Pont, hogy a GPU-d által használt architektúra akadályozza meg ezt, és nem az API-kkal van a gond, mert Turing, GCN és RDNA architektúrával jönnek már az extra fps-ek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#26572
üzenetére
Az már most is van bőven, használj DirectX 12-höz optimális architektúrát: Turing, RDNA, GCN. A Pascal sosem lesz ebben jó. Túl sok dolgot emulál a driver, így a CPU-t terheli.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem kapsz meg mindent, egy rakás funkció kompatibilitási bithez van kötve. Az meg hiányzik a firmwareből. Nem olyan bénák már a gyártók, mint régen, levédik ezt rendesen.
A renderelésen egyébként máshogy is lehet gyorsítani, van egy rakás más rendermotor. De ha nagy sebességet akarsz, akkor a Blender EEVEE egyre jobb. Vagy ha a kritikus felületekre sugárkövetést szeretnél, akkor a ProRender tud full spectrum renderinget. A kritikus felületekre sugárkövetést használ, míg a többire raszterizálást. Két ilyen hibrid opciója is van. Kvázi kevered az EEVEE és a Cycles előnyeit, miközben a sebesség több nagyságrenddel jobb, mint a teljes path tracing.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Kétlem, hogy a 3Ds max Microsoft technológiát fog implementálni a fő leképezőbe, de persze sose lehet tudni, csak az esélye kevés, szerintem. Ezek a professzionális alkalmazások inkább a platformfüggetlenség felé mennek. Plusz nekik a Vulkanba érkező ray tracing valamivel jobb, mert az támogat host oldali gyorsítóstruktúrát, ami nagyon jól jön ám a 32-64 magos processzorok korában. A Microsoftnak erre nincs hasonló megoldása még, aztán lehet, hogy lesz.
Megírtam hírben, amit tudni az Ampere-ről. A többi adat eléggé ködö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 gyorsulás döntő része magából az inline raytracingből fog jönni. Lényegesen előnyösebb a hardvernek, ha csak arra van utasítva, hogy csinálja meg a bejárást, és ha az eltalál valamit, akkor térjen vissza az eredményével, majd ugyanabban a shaderben folytatja vele a munkát. Ezzel a shader lefutásáig minden ott lesz a helyi adatmegosztásban, csak éppen ehhez olyan hardver kell, a teljes munkamenet alatt fenntartja ugyanazt a hardverállapotot, illetve az ütemező végig tudja követni az egyes sugarakat.
A DXR 1.0 nem így működik. Ott külön shader felel magának a sugárnak az indításáért, külön shader fut hit vagy miss esetén, és ezektől függően külön shader indul a bejárás eredményére építve. Ez mind azért probléma, mert minden egyes shader csak egymás után futhat le, ugyanis egymás eredményére várnak, és meg kell oldani az adatok megosztását is, hiszen effektíve egymás eredményeivel számolnak tovább. Ez nagyon rossz hatékonysággal működteti a mai hardvereket, mert egyrészt a függőség akadályozza az optimális, adatpárhuzamos végrehajtást, másrészt, ha nincs valami trükkös módra lehetőség az adatok átadása szempontjából, akkor minden shader kiírja a memóriába, majd a következő shader beolvassa, vagyis egy rakás üresjárat lesz a hardveren, amíg az adatok beérkeznek. Ez a megoldás akkor hasznos igazán, ha nagyon komplext shadereket ír egy fejlesztő, de egyelőre a teljesítmény hiányzik a hardverekből, így ez a veszély az esetek 99%-ában nem fenyeget. Emiatt is jön az inline raytracing, ami a DXR 1.0 modelljét egy sokkal hatékonyabbra cseréli.
Korábban ez azért nem jött, mert ennek azért hardveres követelményei is vannak. Alapvetően egy jobb ütemező, mint ami a mai hardverekben van, illetve meg kell oldani, hogy az egész munkamenet, amivel a sugárkövetés jár, egy hardverállapotból legyen elvégezhető. A legjobb egy stateless megoldás, vagyis az, ha a hardver a compute shader futtatására, illetve a bejárási feladatokra nem is igényel speciális hardverállapotot.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A gigarays szokás szerint semmit sem jelent önmagában. Sokkal többet fog érni egy ilyen nyers adatnál, hogy új ütemezőt kap az Ampere, amit már az inline raytracingre szabtak, de ez például nem számszerűsíthető. Ez valós gyorsulást hoz. De persze azt hozzá kell tenni, hogy a Turingot meg sosem tervezték inline raytracingre, tehát ott rengeteg tényező az ALU erejéből lesz megoldva, nem pedig célhardverrel.
A valóságban a részegységeknél nagyságrendekkel többet fog érni az, hogy egy shaderen belül csinálhatod a sugárkövetést. Nem kell hozzá egy rakás shadert egymás után sorban indítani, meg ehhez az adatokat átadni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A COD Warzone-nak van egy csomó specifikus bugja, a CSGO egyszerűen nagyon régi. Próbálj valami olyan játékot, ami modern is, de nem az elmúlt egy-két hónapban jelent meg. Mondjuk valamit a múlt év őszéről.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mármint mindenki elérheti. De eddig is odaadták mindenkinek, aki kérte. Sry, de ez külön cikket nem ér meg. Maximum belerakhatom az amúgy is készülő, fejlesztői eszközök hír mellé, mert tényleg azt lehet csak ezt lehet leírni róla, hogy most jelentették be, de már hónapok óta létezik, és alkalmazzák is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
yagami01
#26498
üzenetére
Azt mondták nekem, hogy van benne igazság, de nem minden adat stimmel. Amit kiszedtem a szokásos forrásomból, azt megírom, illetve már megírtam, csak megjelenésre vár.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
T.Peter
#26477
üzenetére
Nem lehet. Az a lényege az új futószalagnak, hogy olyat lehessen benne csinálni, amit a régiben nem lehet.
A level dizájn annnyiban egyszerűbb kérdés, hogy ott csak annyi kell, hogy lestoppolod a játékot egy loading felirattal, hogy utolérhesse magát. Az Oblivion és a Skyrim is tartalmaz ilyet, de amúgy megfelelő gépen végig lehet baktatni töltés nélkül is a térképen. A gyengébb gépeken, viszont dob be időnként egy betöltést. Ebből a szempontból ez nem akkora gond.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Olvasd el még egyszer. Egyetlen cég sincs benne kiemelt szerepben. De bizonyos technikai háttér olyan cikkben van benne, amelyik cég éppen először előállt a koncepcióval. A VSR az NVIDIA Turing elemzésben, a primitive shading a Vega elemzésben, de be van linkelve más cikk is. Végig lehet őket olvasni. Nincs elrejtve semmi. Viszont eléggé hosszú lenne leírni, hogy maga a mesh shading mire jó, miközben a Vega cikkben egy oldalt szenteltem már neki. Elég azt elolvasni, és ott vannak a részletek. Az API-t szabvány szempontjából mutatom be, csak részletezem, hogy mit lehetne azon kívül kezdeni, hogy sok-sok évre leülünk és várjuk, hogy kikopjanak a legacy hardverek.
A támogatásra vonatkozóan a végén van információ. Addig nem is foglalkozik az anyag ezzel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Fel van vázolva nagyon részletesen a helyzet. Az összes korábban írt írás be van linkelve a témában.
Az API-s hír topikjában pedig részletesen leírtam, hogy miért lenne jó ezeket a hardveres képességeket elérhetővé tenni driveres átfordítással, mert maga a mesh shader a kompatibilitás miatt még sok-sok évig csak porosodni fog. De ha a legacy kódokból is el tudnák érni a wave intrinsics lehetőségét, akkor azért lenne valami haszna a beépített új módoknak, így az átmeneti 3-4-5 éves időszak alatt is ilyen formában működhetne a hardver. Szerintem ez messze nem lenne elhanyagolható tényező, mert enélkül teljesítmény marad a rendszerben. Mert azt nem fogod látni a fejlesztőktől, hogy a vásárlóbázis 99%-át inkább elengedik, csakhogy a legújabb hardverekre dolgozzanak. Ilyen váltás ráadásul sosem volt, hogy a régi futószalag kompletten kukázva lett, mindenféle opcionális kompatibilitási lehetőség nélkül. Még az olyan újításokhoz is évekig nem nyúltak a fejlesztők, mint a geometry shader, pedig az csak egy új lépcső volt, nem egy komplett reset, ami megköveteli az összes eddig megírt kód kidobását (ilyenből azért van úgy bő 40 ezer sornyi shader a modernebb motorokban). Azokat most el lehet kezdeni nulláról újraírni. De ha mondjuk a driver megengedné, hogy ezeket a shadereket addig is lehessen úgy használni, hogy majd befordítja a hardvernek a driver a jobb geometriai módokba, akkor az nem lenne azért rossz. Már csak azért is, mert teljesítményt nyernél vele.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Eleinte nem lesz olyan multiplatform cím, amely nem fognak kiadni last gen konzolokra. Ezek az új képességek akkor fognak számítani, amikor elég next gen konzol került eladásra, hogy a fejlesztők csak azokat tudják célozni, mert úgy is visszahozza a fejlesztési költséget. PC-n valószínűleg még később, mert nagyon lassan kopnak ki a régi hardverek.
A Turing nem támogatja ezt driveresen. Nem tudni, hogy megoldható-e azon. Azért nem olyan triviális kérdés ez, hogy azonnal menni fog. Lásd a Vega esete, aminél az átfordítás nem működik, pedig a hardver ugyanaz.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem kötelező ráfeküdniük a driveres megoldásra, de a driveres megoldás akkor is működik, ha az alkalmazásban nincs egy deka mesh shader sem, míg a natív megoldáshoz utóbbi elengedhetetlen. Viszont a futószalag annyira módosult, hogy ilyen játékot nem fogsz látni sok évig. Egyszerűen nagyon számít, hogy a régi hardvereken is elinduljon a program, mert sokan azért nem vesznek sűrűn új hardvert.
Tehát a driveres megoldás csak egy lehetőség. Az AMD pont azért csinálja, mert még évekig legacy kódok lesznek a játékokban, amíg ki nem kopnak azok a VGA-k és platformok, amelyek nem támogatják a hatékonyabb geometriai futószalagot. Addig viszont jobb megoldás nem porfogónak használni az erre felhúzott hardvert, hanem a legacy kódokat érdemes belefordítani.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De ezaz. Lényegesen nagyobb terhelést raktak bele, mint az eddig megjelent RT programokba. A dizájnja amúgy szar. Nem véletlen, hogy ma már nem nagyon csinálnak technikai demókat a cégek. A tehetséges tartalomkészítőket felszívja a játékpiac, így meg marad a fos tartalom, de ettől a számítás mennyisége ugyanaz.
Egyébként az még a kérdés, hogy mennyit nyer az inline futószalagból, mert ez a demó konkrétan csak egy shadert futtat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A GAB tagok persze, hogy tisztában vannak ezzel. Ők találják ki, mindenki, aki tag. Amivel nincs tisztában az NV az a konzol működése, de olyat meg kérhetnek. Bár ugye ettől még azt nem tudhatják, hogy a szoftverben mennyi tartalék lehet.
A DXR 1.1 egyébként eléggé az Xboxhoz lett tervezve. Nem azért mert nagyon ez kell a hardverhez, hanem azért, mert maga az inline megoldás a sugárkövetésre gyorsabb lehet sok esetében a korábbi megoldásnál. És azért ez számít a konzolnál.
Az AMD a Microsoft prezijén mutatott egy RDNA2 demót. Kérdeztem őket, Xbox Series X-en futott, és tele volt RT-vel, elég keményen. Nem tudom, hogy felrakják-e valahova.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ugyanezt írja az AMD sajtóközleménye is.
Ezek marketinganyagok.
Amúgy az AMD a FAD rendezvényen is azt mondta, hogy a DXR 1.1-et a Microsofttal közösen dolgozták ki.
Ezekben annyi az igazság, hogy a gyártók részei a GAB-nak, és így minden, amin a Microsoft dolgozik egy olyan technológia, ami a GAB-ban résztvevő gyártókkal közösen lett kifejlesztve.
Szerintem várhatjuk az Intel közleményét is. Ők is GAB tagok.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
hokuszpk
#26437
üzenetére
Nem érdemes annyira nagy hangsúlyt fejtetni egy számra. A sugárkövetés sokkal bonyolultabb annál, hogy csak az IPS alapján le lehessen vonni következtetés. Már csak azért is, mert ezt már maguk a körülmények is befolyásolják.
A sugárkövetés teljesítményének meghatározásához meg kell határozni magát a körülményt, és ezután szükség van a TFLOPS, TOPS, IPS és GB/s-ra is, mert ezektől mind függ.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
hokuszpk
#26432
üzenetére
Le tudják mérni a két új konzolban az RT-t. A boxban "up to 380 billion intersections per second". Megkérdezik a fejlesztőket, hogy mi volt a körülmény, és tudják is. Esetleg szereznek maguknak gépeket. Az NV még kapna is, mert vannak saját middleware-jeik az aktuális konzolokra, és azokat nehéz portolni az újakra, ha nem jutnak hardverhez.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ha a kamera mögötti pontból lövöd ki, akkor nem lesznek párhuzamosak, de ettől igaz rájuk, hogy két egymás melletti sugár nem messze metszi majd a geometriát, tehát cache-re lehet ott még építeni. Visszaverődés után viszont már nem, mert egészen más helyre tarthatnak az új sugarak. Ezért jön elő a véletlenszerű adatelérés problémája a sugárkövetésnél. Ez a kulcstényező, amit miatt ez nehéz, mert mindig a memóriáig kell menni az adatért. Nem lesz ott a cache-ben, mint mondjuk a primary ray esetén, vagy a raszterizálásnál.
Ezt a gondot vagy koherenciadetektorral (most vegyük ezt elméletire, nyilván ennek is van egy hatékonysága), vagy pusztán nyers sávszélességgel lehet megoldani.A sugarakat úgy lövöd amúgy ki, ahogy akarod. A kérdés, hogy mit szeretnél. Viszont maga az alaptézis, hogy az egymás mellett futó sugarak, legyenek azok párhuzamosak, vagy sem, alapvetően lehetőséget adnak a cache-elésre. Onnantól válik az egész nagy problémává, ha visszaverődnek, és a secondary ray-ek teljesen más irányba fognak tartani.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#26310
üzenetére
Tehát ha ő beszél a véletlenszerű adatelérés problémájáról, akkor az jó, ha én, akkor az nem. Akkor nem is azzal van gond, hogy mi lett leírva, hanem azzal, hogy ki írta. Még jó, hogy bemásoltam Ben Archard leírását is a problémáról, így mindenki láthatja, hogy mi a helyzet itt. Köszönöm, hogy tisztázni tudtuk ezt a helyzetet, további jó trollkodást.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#26308
üzenetére
Értem. Sajnálom magam és Ben Archardot is a Metro Exodus grafikus fejlesztőjét, hogy nem érti a sugárkövetést, és a véletlenszerű adatelérés problémájáról beszél. Hála az égnek, hogy vagytok ti, akik sose írnak semmiről részletesen, de megmondjátok, hogy én, illetve az az ember, aki sugárkövetést rakott egy AAA játékba hülye. A nevében is köszönöm, hogy remek hsz-eitekkel emelitek az internet adatforgalmát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26303
üzenetére
Ha írtál valaha ray tracert, akkor pontosan tisztában kell lenned, hogy az adatelérés véletlenszerű mivolta miatt kell a rengeteg memória-sávszélesség hozzá. Innentől kezdve nem értem, hogy miért kérdezed ezeket. Csak megtanították ezt az egyetemen.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26301
üzenetére
Mégis én írom le kettőnk közül, hogy miképp működik, míg te csak azt írod, hogy nem vagyok vele tisztában. Mindenféle rosszindulat nélkül...
Egyébként ha nekem nem hiszel, akkor itt van Ben Archard a Metro Exodus motorprogramozója [link]:
"The nasty thing that ray tracing does, as opposed to something like say SSAO, is randomly access memory. SSAO will grab a load of texel data from a local area in texture space and because of the way those textures are stored there is a reasonably good chance that those texels will be quite close (or adjacent) in memory. Also, the SSAO for the next pixel over will work with pretty much the same set of samples. So, you have to load far less from memory because you can cache and awful lot of data.
Working on data that is in cache speeds things up a ridiculous amount. Unfortunately, rays don't really have this same level of coherence. They can randomly access just about any part of the set of geometry, and the ray for the next pixels could be grabbing data from and equally random location."
Tehát alapvetően a sugárkövetés problémája az, hogy az adatelérés túl véletlenszerű ahhoz, hogy a cache-ekre valóban építkezni lehessen, márpedig ezen csak a nagyobb memória-sávszélesség segít.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Itt nem a pixelekből lövöd ki a sugarakat, hanem egy kamera mögötti pontból. Ugyanakkor a koherencia itt is elég jó, mert jó esély van rá, hogy két egymás melletti pixelen áthaladt sugár egymáshoz közeli texelcsoportot talál el.
A secondary ray esetében az a gond, hogy teljesen más irányba is mehet a sugár a visszaverődés után, annak ellenére is, hogy mondjuk egymás melletti primary ray-ből származik. Ezzel elveszted a cache-elhetőséget. Ezért csinált egy külön hardvert az Imagination, ami képes csoportosítani a sugarakat, és direkt úgy számolja azokat, hogy annyira ne legyen összeszemetelve a cache. Persze ez sem tökéletes módszer, és relatíve nagy hardvert igényel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26282
üzenetére
Kamera. Amikor a teljesítmény lényeges a reserve ray tracing a kifizetődő. De egyébként támogatja a fényforrásból való kiindulást is a rendszer, csak sok haszna ennek ma nincs, mert elég nagy a valószínűsége, hogy a jellemző, igen korlátozott számítási távolságig nem fogja eltalálni a kamerát a sugár. Ahhoz sokkal tovább kellene számolni, de ahhoz meg nincs erő a hardverekben.
A például a pixelekből kilőtt sugarak a kamerára merőlegesek, így mindegyik párhuzamos egymással.
Semmi. Mivel két egymást követő frame között nincs frame-számítás, így irreleváns, hogy a jelenet hogyan változik. Nem kapsz róla visszajelzést a kijelzőn. Ettől persze a szimuláció megtörténhet, csak az eredményét nem látod.
Amióta az ALU-kat felkészíti lebegőpontos feldolgozásra is. Ha nem ilyenek lennének a GPU-kban az ALU-k, akkor nem tudnának FP műveletet számolni a hardverek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26280
üzenetére
A primary ray az a legelső reverse ray, aminél azért van lehetőség cache-elésre, mert mindegyik pixelből származó sugár párhuzamos a másikra. A secondary ray az összes többi, ami a primary rayből származtatott. Ezeknél azért nincs lehetőség a cache-elésre, mert teljesen véletlenszerű az egész, egyszerűen az egymáshoz közeli primary rayek secondary sugarai teljesen máshova futhatnak. Emiatt ugye a secondary ray esetében nem alkalmazható az az elv, ami a primary ray-knél, hogy az egymás melletti sugarak ugyanahhoz a textúrákhoz tartozó texeleket találják el, vagyis nem tudsz arra építeni, hogy betöltesz a textúra gyorsítótárba egy adott texelcsoportot, majd abból egy jó darabig megélsz. Menni kell minden egyes secondary ray-nél a memóriáig. Ráadásul ez véletlenszerű hozzáférés, ami a legrosszabb.
A HBM csak a sávszél miatt kell. Világos, hogy nem lehet gigabájtos méretű cache-eket építeni a GPU-kba, tehát amikor a cache-elés már nem lehetséges, akkor onnantól kezdve a memória-sávszélesség lesz a limitáló tényező, mert adat nélkül hiába vannak TFLOPS-os számítási kapacitású ALU-jaid, előbb be kell olvasni azt, amivel számolni tudnak.
Alternatív lehetőség a koherencia csoportosító, amit az Imagination csinál a PowerVR Wizard GPU-nál. Ez egy opcionális hardver, amely megpróbálja kitalálni, hogy melyik secondary ray-ek tartanak hasonló irányba, és a feldolgozásuk előtt ezeket csoportosítja, majd úgy történik meg a hardveren a számításuk, hogy az azonos csoportba tartozó sugarak kvázi együtt lesznek kalkulálva. Ezzel biztosítva a cache-elhetőséget. Nem szuper módszer ez, de hatékonyságban sokkal jobb, mint a brute force megoldás, amit például az NVIDIA csinál. Ugyanakkor számításba kell venni, hogy az ehhez szükséges hardver elég sok tranzisztort igényel. Az Imagination esetében gyakorlatilag ez a koherenciadetektor majdnem akkora, mint maga az egész GPU, és amíg elvétve vannak hibrid sugárkövetést támogató játékok, addig érdemes feltenni a kérdést, hogy megéri-e tranzisztorok milliárdjait olyan hardverelemekre költeni, amelyek kb. egy tucat játékban hasznosulnak, míg a többiben nem csinálnak semmit. Az NVIDIA ezért alkalmazza a brute force módszert. Grays/wattban ugyan messze elmaradnak az Imagination megoldása mögött, de arányaiban sokkal kevesebb tranyót is költenek rá. Tehát nem egyértelműen az a jó, ha elkezded hardveresen kezelni az egyes problémákat. Sokszor hasznosabb együtt élni ezekkel, és rakni a secondary ray-ek alá 1-2 TB/s-ot, vagy ahogy manapság csinálják, hogy gyakorlatilag 2-4 virtuális méternél tovább nem is számolnak sugarat, ami nem túl jó az eredményre nézve, de kétségtelenül eléggé tudja kímélni a sávszélt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#26258
üzenetére
Mert a sugárkövetésnél csak a primary ray-ek koherensek, tehát csak ezek cache-elhetők. Minden secondary ray nem koherens, vagyis teleszemetelik a cache-t. Így minden secondary ray esetében a memória-sávszélesség a döntő tényező a sebesség tekintetében, hiszen sosem lesz ott a szükséges adat a gyorsítótárakban.
(#26252) b. : A konzolnál felesleges ezt számolgatni. Ott a játékokon jön a zsé, tehát a gépet lehet akár veszteséggel is adni. Az árszabásnál nem az előállítási költség lesz a döntő, hanem az, hogy eladjanak elég gépet az optimális platformbázis kialakításához, hogy a fejlesztők elkezdjenek rá dolgozni.
(#26261) huskydog17: 512 bitet nagyon nehéz építeni ezekkel a magas effektív órajelű memóriákkal. A Micronnak a referencia-NYÁK-ja 55 cm. Ezt talán le lehet vinni 40-45 cm-re, de biztos nem 16 Gbps-mal. Egyszerűen nem lehet jól leárnyékolni a magas fogyasztású hardvereket. Ennél nagyobb probléma a fogyasztás. Egy 16 darabos 12 Gbps-os GDDR6-os pack, ami minimum kell az 512 bithez, 40 wattot eszik. Egy hasonló teljesítményű HBM2 stack 2 watton belül megoldja ugyanazt. A 40 watt már probléma, mert ennyivel kevesebb fogyasztási kerete marad a GPU-nak, ami jelentős teljesítményhátrány a HBM2-höz képest. Plusz, ha sok memória kell akkor 32 GDDR6-ra van szükség, ami viszont 80 watt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#26111
üzenetére
Az ilyen bemutatókra azért csinálják így, mert az összevetéseket külön csapatok végzik. Emiatt van a review guide, ami már egy tesztgépben néz mindent, ugyanolyan beállításokkal, ugyanolyan OS-sel, stb.
Természetesen a guide így más eredményeket szokott adni, mint a bemutatóra készült mérések. Eleve sokkal több játék van benne.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezeket nem nehéz megtudni. A szerződést nem adják ki, de elég sokat tudnak a cégen belüli emberek róla.
Nekem mindegy, hogy mit hiszel el. Hiheted azt is, hogy az NV leszállította nekik a nyáron a kódot, de a Bethesda azt mondta, hogy várjunk még fél évet ezzel, addig is elrakjuk a patch-et.
A VK_NV_ray_tracing egy kiterjesztés. És ez a kiterjesztés nagyon fog hasonlítani az EXT kiterjesztésre, ami készül belőle, tehát azonnal működni fog bármin, ami nem NV. Nem kell átírni a kódot, csak ki kell cserélni a kiterjesztés ellenőrzését. Nyilván itt a megszokott dolog történik majd. Átviszik az egészet EXT-be, majd az EXT-ből lesz egy KHR verzió. A Khronos a Vulkant nem hagyja úgy elkallódni, mint az OpenGL-t, így egy problémára csak egy megoldás lesz végül, ami mindig KHR.
Az adaptive shadingre ugyanúgy lesz EXT kiterjesztés, az is ugyanúgy jó lesz bármilyen hardverre.Ezekre a kiterjesztésekre a fejlesztők implementációkat írnak. Vagy saját maguk, vagy ha ezt az időt meg akarják spórolni, akkor kérnek készre megírt effekteket a gyártóktól, de ahogy fentebb írtam ez nehéz ügy lehet esetenként, így lehet, hogy meg kell írni saját maguknak, ami természetesen beletelik több hónapba. Abban nincs szerintem vita köztünk, hogy sokkal egyszerűbb lenne lemásolni egy implementációt, majd kb. két hét múlva kiadni, csak nem biztos, hogy erre jogi szinten lehetőség van az iparágon belüli egyre kuszább szerződések miatt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Bethesdától. Elég komplex szerződésük van még az AMD-vel, amit pár éve kötöttek a Prey előtt, és még négy évig érvényben marad. Ezt egyébként az AMD is mondta nekem a múlt évben. A szerződés nem tiltja, hogy az NV felhasználjon egy olyan címet marketingre, amit az AMD nem kért, de azt tiltja, hogy bármilyen kódot, amit az NV adott felhasználjanak. Mindent saját kút főből kell írni a szabványos rendszer erejéig. Ezért tartott ennyire sokáig ezt implementálni, mert az NV-nek sok kódja van ezekre az effektekre, csak nem nyúlhatnak hozzájuk. Viszont megírhatják maguk, azt nem tiltja semmi, ráadásul ez amúgy is jobb megoldás, mert így gyors is lesz a játék. Az AMD-nek amúgy is a CPU-ra kell a Bethesda, mert az id tech 7-et úgy írták meg, hogy nagyon-nagyon sok magra skálázódjon.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
imi123
#26089
üzenetére
Semmi közük nem volt hozzá. Az id tech magának csinált mindent, hogy ne kelljen mással megosztani a kódjaikat, illetve saját maguknak akarták kontrollálni a teljesítményt. Az NV csak a kiterjesztést adta, semmi mást. Részben ezért is csúszott, mert az id házon belül csinálta meg, az NV nélkül.
A beharangozás nyilván kellemetlen volt, azért tartották a hátukat, de a Zenimax nem szereti, ha a technológiáikat más fejlesztő is felhasználja. Azért ez mégis egy verseny, ha ők beleraknak egy csomó pénzt, akkor annak az eredményét szeretnék maguknál tartani. Persze van aki nem így gondolkodik, most ez nézőpont kérdése.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Sokkal többet csökkentesz a késleltetésen, ha bedobsz a driverbe egy scene pacinget, és akkor a GPU azonnal kezdi a jelenethez tartozó képszámítást, majd azonnal küldi az eredményt a kijelzőre. Ilyen szempontból erre hivatkozni egy bullshit, mert már azon egy rakás késleltetést veszít a rendszer, hogy minimum két jelenetre előre van generálva a parancslista, vagyis egy ilyen kijelzővel visszanyersz az itt elbukott kb. 10 ms-ból másfelet. De ha a driverben kérsz egy scane pacinget, akkor nem másfelet nyersz, hanem azt a 10 ms-ot, amit a parancslista működése generál, és még ilyen monitor sem kell hozzá. Szóval attól, hogy egy monitor 360 Hz-en frissít, még a képszámításért felelős alapértelmezett pipeline ugyanolyan szar marad.
Ha pusztán az emberi látásból indulunk ki, akkor nagyjából 144 Hz-nek van racionálisan értelme. Minden efölött vagy valamilyen bugból, vagy azért ad rossz érzést, mert a képszámítás maga van rosszul vezérelve, és feltorlódnak a jelenetek a parancslistába, ami egyébként szintén lehet bugtól. Frissíthet a monitor 1000 Hz-en is, nem magát a problémát kezeli, így igazán látható előnye a 144 Hz-hez képest nem lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
paprobert
#26073
üzenetére
A 240 Hz-nek sem az a lényege, hogy jól meg tudja csinálni a kijelző, hanem hogy papíron rá lehessen írni. 120/144 Hz fölött nincs akkora haszna ennek, mint amennyi problémát behoz a panel hiányosságai miatt. De a lényeg, hogy papírja legyen a 240 Hz-ről, mert a gémerek így hajlandók többet adni érte. Azért senki sem fizetne többet, ha azt írnák rá, hogy 240 Hz, de kapod a jókora over/undershootot, majd ha ezeket valahogy próbálod kezelni, akkor jön a haloing, stb. Ez majd akkor kiderül, ha kipróbálod.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az NVIDIA éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Axon Labs Kft.
Város: Budapest