- Már tudjuk, hogy mikor jön pontosan az idei Ubisoft Forward
- Napokon belül indul a testkamerás Bodycam című FPS korai kiadása PC-n
- 2024 - Íme a 23. héten megjelenő játékok listája
- The First Descendant - Napokon belül megkapjuk a megjelenési dátumot
- Megjelenési dátumot kapott a Tomb Raider animációs sorozat
-
GAMEPOD.hu
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
-
-
-
-
-
Ribi
nagyúr
válasz Jack@l #23945 üzenetére
Igen és?
Annyira jó, hogy irkál mindenki össze vissza, de hogy ezzel mit akar mondani az nincs.
Akkor az most sok vagy kevés vagy mi?
2060 egy kicsit kevesebb mint felezett 2080Ti. Ehhez mérten kicsit kevesebb mint felezett eredményt hoz. Akkor ezen most van bármi meglepő? Vagy túl jó?[ Szerkesztve ]
-
Yutani
nagyúr
válasz Jack@l #23954 üzenetére
Almát hasonlítasz körtéhez. Csak úgy tudnád kimérni a sávszél hatását, ha fognál egy Titan V-t és lecsökkentenéd a memória órajelet, majd úgy is megmérnéd a RT sebességét.
RT célhardver esetén annak képessége fogja meghatározni a sebességet, nem a memória sávszél a kártyán, lásd fentebb a kolléga megjegyzését a 2070-ről és 2080-ról.
#tarcsad
-
Yutani
nagyúr
válasz Jack@l #23960 üzenetére
Érdekes. Vegyük a GTX 980-at és GTX 1060-at. Általános teljesítményben nagyon közel vannak egymáshoz, TPU szerint 1-2% távolságban. Ezt az első teszt nagyjából visszaigazolja, ahol a 980 picit a 1060 előtt van (~3%), annak ellenére, hogy a mem sávszél rendre 224 GB/s, illetve 192 GB/s.
Viszont mi van a második teszttel? Ott a különbség ~21% a 980 javára, pedig a MAxwell mem sávszél előnye csak ~17%.
A Radeonoknál meg aztán borul minden, a jóval magasabb sávszélességgel dolgozó GCN2 és GCN3 csúnyán elmarad a GCN4-től. Itt jól láthatóan a GPU uarch az, ami korlátozó tényező.
Mi a tanulság szerinted?
#tarcsad
-
nagyúr
válasz Jack@l #24111 üzenetére
A tradicionális terhelésekre gyenge. A "majd egyszer"-t pedig már régen letrademarkolta az AMD...
(#24112) KillerKollar: valóban. Akkor négy, műszaki fronton duplán. Tényleg csodálkozni kell, hogy nem viszik, mint a cukrot
Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
nagyúr
válasz Jack@l #24116 üzenetére
Ugyan. Jelenleg pont ugyanaz a helyzet, mint az összes AMD-s hagymázas lázálomnál - a hardver ott is mindig kész volt, a szoftver meg majd jött. Vagy nem. Hogy az NVIDIA-nál mi fog jönni, az jelen pillanatban hitkérdés - pont ugyanolyan, mint az AMD találgatósban minden generációnál felbukkanó csodaújdonságok.
Amúgy szerintem a RT esetén nem is az a legnagyobb probléma, hogy szinte nincs értelmezhető kontent (pedig az is elég nagy), hanem az, hogy a generál reakció az rá, hogy "miezafaszsághogycsakfullhdbenvanelégfps". Ha a közönség ennyire leszarja azt a képminőségbeli dimenziót, amit a raytracing teremt, és csak a számok hajhászása az érdekes, akkor az hosszabb piaci küszködést vetít előre. Persze el tudok képzelni erre megoldásokat, és ha én el tudok, akkor Jensen marketinges szabadcsapatai biztosan szintén el tudnak x100, csak az könnyen lehet, hogy eladható lesz, ám szar.
Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
Abu85
HÁZIGAZDA
válasz Jack@l #24125 üzenetére
Nyugodtan. Az EPIC roadmapjéből származik. Aki UE4-gyel akar DXR-t, annak magának kell implementálnia. Az EPIC egyhamar nem teszi ezt meg.
(#24126) b. : De az EPIC az nem az NV. Az UE4 az egy igen szabadon licencelhető motor. Az NV csinálhat hozzá magának DXR forkot, stb. Azt persze nem fogja támogatni az EPIC, de nem ez lenne az első, levégre van egy rakás GameWorks forkja az UE4-nek. Viszont az EPIC teljesen másképp működik. Ők nem foglalkoznak azzal, hogy az NV milyen mellékszálakat készít. Nekik van egy főverziójuk, és azt fejlesztik, azt támogatják is, stb. Ettől nem tiltják, hogy valaki egy alternatív forkot használjon, csak ha probléma van vele, akkor le se szarják, hogy nem működik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
nagyúr
válasz Jack@l #24119 üzenetére
A DX12-re is rá volt. Örülni fogok, ha lesz belőle valami, csak éppen hinni nem hiszek benne, hogy ez a közeli jövőben történik.
(#24120) Abu85: ja kb. Az RT alapvetően egy másik renderelési módszer, nem értem a kirakat-effekteket, főleg nem az olyanokat, mint az AO vagy az árnyékok. A reflectionnek még talán van is értelme.
[ Szerkesztve ]
Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
Abu85
HÁZIGAZDA
válasz Jack@l #24135 üzenetére
Hát, az EPIC felkötheti a gatyáját. Neki se kezdtek még. Ne érts félre én szurkolok, hogy megcsinálják két hónap alatt, de nekem Rolando azt írta nemrég, hogy a következő nagyobb frissítésnél a fókuszt a Vulkan leképező befejezése jelenti, hogy minden DirectX 11-ben elérhető funkció hozzáférhető legyen ezen az API-n is. Emellett ugye végre jön az explicit parallel RHI, amivel már nem kell, hogy a DX11 legyen a default renderer. Majd tartanak a GDC-n egy közös előadást az Intellel az új UE4 fejlesztésekről. (nem tőlem tudod )
Márciusban maximum egy forkot mutat fal talán az NV, de ezt meg az EPIC nem támogatja, tehát sok fejlesztőt nem fog érdekelni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
félisten
válasz Jack@l #24174 üzenetére
Nem tudom emlékszel e GC-n jensen arról magyarázott, hogy a textúrákat kipótolja a DLSS, hogy pl egy él kerek legyen, vagy egy kör alak valóban kör legyen, ilyesmi.De azért itt nem stimmel valami.
Mondjuk nem egy hivatalos tesztből van hanem egy hobbi user videója, lehet ő cseszett el valamit vagy manipulált dolgokat a két teszt között, ez benne van a pakliban.Benézek RTX topikba hátha valaki lefuttatja így aztán feldobja YT-ra.[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
félisten
válasz Jack@l #24176 üzenetére
Persze adom amit írsz, de gyanakszom arra, hogy a srác nem azonos beállításokat használt a két teszt alatt a DLSS en kívül is.
Mondjuk a képeken szerintem szebb több helyen a javított kép[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
félisten
válasz Jack@l #24244 üzenetére
jaja tudom, de a tesztet is elszúrták, az eredményeik sem jók. A TPU tesztben szerintem jobba RTX és van külön DLSS összehasonlítás is, érdemes megnézni.
DLSS: [link]
RTX: [link]"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
BiP
nagyúr
válasz Jack@l #24259 üzenetére
Úgy érted, a raytracinghez a hagyományos AA algoritmusok nem elég jók, ezen segíthet a DLSS ?
A cikkben csak a fordítottját említik, hogy a DLSS bekapcsolásához kell az RTX.(#24257) regener: Mondjuk én eddig csak a Final Fantasy összehasonlításokat láttam, az nem győzött meg. (mondjuk ott maga a benchmark is ocsmány)
BF5-ben lehet, hogy jobban ment a tréning, és emiatt szebben sikerült a DLSS.[ Szerkesztve ]
-
BiP
nagyúr
válasz Jack@l #24264 üzenetére
Na, így már legalább értem, miért írtad azt, hogy "raytracing miatt kell"
"amúgy a minősége az nagyon gagyi" - nekem ez a bajom vele.
"kicsit jobb minőségű felskálázásra találták ki" - arra egyébként még jó is végülis. Kár, hogy nem így kommunikálták, hanem az 1440p-s rendert adják el 4K-nak. -
BiP
nagyúr
válasz Jack@l #24264 üzenetére
"Ha így jobban tetszik: kicsit jobb minőségű felskálázásra találták ki"
Úgy látszik, arra sem jó igazán. [link]Sosem tetszett a DLSS koncepciója, kommunikációja, ez a videó meg végképp meggyőzött arról, hogy ez így ebben a formában inkább kerülendő (részemről mindenképp).
Pedig ez az NV cikk [link] picit segített megérteni, hogy miért úgy kommunikálják, ahogy, de akkor sem szeretem a marketingtrükközéseket. -
Abu85
HÁZIGAZDA
válasz Jack@l #25597 üzenetére
Az MS demóappja azért jó, mert maga a felépítése miatt kellően koherensek a sugarak. Egy játékban még ennyire sincs kihasználva az RT mag, mert a nem koherens sugarak a cache-t összeszemetelik, illetve rengeteg véletlenszerű memóriaelérést igényelnek. Tényleg fontos az elméleti adatot a gyakorlattól megkülönböztetni. Ezt az NV is eléggé hangsúlyozta a GDC-n, hogy elméletben beszélnek 6-8-10 GRays/s-ről, de ez egy koherens sugarakon, shading nélkül mért érték, egy amolyan abszolút maximum, amire elméletben képes a hardver, ha más komponens nem fogná vissza. A játékban ilyen helyzet nincs, így ott már igen jó értéknek számít az 1-2 GRays/s is. De ez nem amiatt van, hogy az RT mag nem lenne elég jó, hanem amiatt, hogy nem tudja etetni a rendszer többi komponense, elsődlegesen a memória, mert túl lassú ahhoz képest, amilyen gyorsan maga az RT mag tudna dolgozni. Emiatt nincs igazán értelme az RT magot erősíteni, mert már így is sokkal erősebb annál, amire lehet használni. Etetni kellene, ez az elsődleges probléma, aztán az már nézőpont kérdése, hogy ezt koherenciamotorral, vagy brute force memória-sávszélességgel érik el.
[ 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 #25602 üzenetére
Mert a valóságban nincs is olyan, hogy RT mag. Az rendben van, hogy ezt számszerűsítik magokkal, de valójában egy nagy fixfunkciós hardverről van szó, ami a bemeneteket per multiprocesszor kapja. Kb. a raszterizálóhoz hasonló az egész. Csak ahogy itt leírtam: [link] - a sugárkövetésen nem segít a cache, mert nem alkalmazható rá a lokalitási elv, emiatt minden egyes mintáért menni kell a memóriába, míg raszterizálásnál hiába történik hasonló mennyiségű adat feldolgozása, akkor is nagyságrendekkel kevesebbszer kell a memóriába menni az adatért, mert nagyon jól működik a lokalitási elv. Emiatt mindig a memória lesz a szűk keresztmetszet, mert nem tudod igazán bevinni a számítást a lapkán belülre. Még koherenciamotorral sem, bár az sokat segít.
(#25603) b. : A chiplet nem igazán jó a sugárkövetésre, mert akkor meg a mintát szállítani kell a lapkák között. Azt is csak a memóriával tudod megtenni, különben alaposan túlterheled a buszt, amire a legkevésbé sem vágysz egy GPU-nál. Amikor mintavétel van, akkor az a lényege neki, hogy ott legyen a textúra gyorsítótárban az adat, az mindegy, hogy raszterizálással vagy sugárkövetéssel vetted a mintát. Ha ezt a problémát kihelyezed egy külön lapkára, akkor az történik, hogy az adat nem ott lesz, ahol kellene lennie, vagyis el kell menni érte egy lassú buszon keresztül. Ráadásul az adatlokalitás kifejezetten rossz sugárkövetéssel. A CPU-knál azért működik ez a chiplet dizájn, mert ott van magonként 2-4 szál, és a feldolgozás jellege is olyan, hogy nagyon lehet építeni a lokalitási elvre. Egy GPU multiprocesszor viszont dolgozik 10-32 wave-vel, wave-enként 32-64 lane-nel, vagyis hardvertől függően 500-1000 konkurens szál fut egy multiprocesszoron, ezeket pedig hardveresen vezérelni kell. Emellett a feladatok végrehajtása sem olyan, hogy ami ideális a chipletnek, mert amíg a CPU-nál eléggé nagy az esélye, hogy egy folyamat azon a magon fejezi be a munkát, amelyiken megkezdte, addig egy GPU-nál eléggé kis eséllyel történik meg az, hogy egy folyamat ugyanazon a multiprocesszoron végez, ahol kezdett. A chiplet úgy működne a GPU-knál, ha az API-ban lenne rá módosítás, ami egyébként létezik is - [link]. Alternatív megoldás lenne egy vezérlőlapka több GPU chiplet mellett, ami igazából azon dolgozna csak, hogy megpróbálja a futó folyamatokat egy chipleten belül tartani, mert ahogy kikerülsz onnan, megdöglik a chiplet buli a GPU-knál.
Azért ez nem atomfizika. A sugárkövetés egyáltalán nem olyan hardveresen, hogy annyira sok lehetőség lenne. Két lépcső van, amit lehet gyorsítani: a bejárás és az ütközésvizsgálat. Utóbbi igazából nem nehéz, és nem igazán kell rá programozhatóság, tehát érdemes gyorsítani. Előbbinél véleményes, hogy a gyorsítás, vagy a programozhatóság ér többet. Arra felé haladunk, hogy a programozhatóság, de a mai DXR verzióban még gyorsítva van. Ezeken kívül a koherenciamotor, amit még be lehet építeni, arra amit fentebb kifejtettem. Na most nagyjából ennyi. A futószalag többi rész shader, tehát a multiprocesszorok ALU-in fut.
Az, hogy mit várok és mi valósul meg, két különböző dolog, de ha már megkérdezted, akkor azt várom, hogy támogatni fogja a következő DXR verziót, így picit át fog alakulni a hardver, hogy jobban tudjon igazodni a programozható bejáráshoz. Az ütközésvizsgálat nyilván marad fixfunkciós. Ahhoz, hogy sebesség is legyen szükség lesz legalább ~1 TB/s-ra, de jövőre realitás a HBM3 is, tehát inkább érdemes ~1,5-2 TB/s közé ugrani. Ez már önmagában elég nagy előrelépés. A koherenciamotorban reménykedem, de nem várom feltétlenül a tranzisztorköltség miatt. Ugye amíg a memóriára vonatkozó változások jelentős előnyt jelentenek általánosan is, a koherenciamotor már nem, így ott van pár erős kontra érv is. Amit az RT-n kívül várok az a variálható warp-méret, amivel erősödhet az egy munkaelemre levetített IPC.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Ú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.
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Samsung Galaxy A55 - új év, régi stratégia
- PlayerUnknown’s Battlegrounds
- Látóhatáron a drágább HMD készülékek
- Egyszerű funkcionalitást kínál a frissen bemutatott Galaxy Fit3
- Villanyszerelés
- EAFC 24
- Ha Trump győz, Elon Musk politikai tanácsadó lehet
- Spórolós topik
- Nem indul és mi a baja a gépemnek topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs