- Csatába küldte Magyarországon idei csúcs hangprojektoros szettjét a Samsung
- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Milyen HASZNÁLT notebookot vegyek?
- 3D nyomtatás
- Azonnali informatikai kérdések órája
- Házimozi belépő szinten
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- AMD GPU-k jövője - amit tudni vélünk
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- TCL LCD és LED TV-k
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
Hirdetés
-
Agyi chipes gyártóba fektetett a kriptocég
it A Tether 200 millió dollárt fektet a Blackrock Neurotech agyi chipes vállalatba.
-
Megjelenési dátumot kapott a Star Wars: Hunters
gp A tervek szerint június elején végre befut a teljes kiadás mobilokra/tabletekre és Nintendo Switch-re.
-
Nemzetközi piacra érkezik az Amazfit Helio Ring
ma Elsőként az Egyesült Államokban lehet majd megvásárolni a gyártó első okosgyűrűjét.
-
PROHARDVER!
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
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
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
#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
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
#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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
#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
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
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
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
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
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
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
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
É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 é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.
-
#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
"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.
-
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
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.
Ezek marketinganyagok.
Ú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.
- Milyen HASZNÁLT notebookot vegyek?
- 3D nyomtatás
- Azonnali informatikai kérdések órája
- Házimozi belépő szinten
- Star Citizen
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Luck Dragon: Asszociációs játék. :)
- Autós topik
- AMD GPU-k jövője - amit tudni vélünk
- További aktív témák...
