-
Fototrend
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
Yutani
#47043
üzenetére
Dolgoznának ők az NV-vel, de nincs megfelelő fejlesztőkörnyezet hozzá. Nem tudom emlékszel-e arra, amikor az Epic váltott hardvert. Készültek a Vulkan API-ra való átállásra, és lecserélték a gépparkot Radeonokra, hogy elérhető legyen a RenderDoc+RGP. Aztán bevetették először az RGP-t, és rögtön találtak a kódban egy olyan bugot, ami még az első rajzolási parancs kiadása előtt 517 darab erőforrás-áthelyezést csinált, és ez tulajdonképpen egyenértékű a hardveren belüli gyorsítótárak 517-szer való egymás utáni ürítésével. Ez elég nagyot ment anno a Twitteren, hogy egy ilyen ordas nagy bugot nem vett észre az NV és az Intel profilozója. Egyszerűen nem látták, hogy a hardver ciklusok tömkelegét malmozza el. És ez minden GPU-t érintett, tehát lelassult a bugtól az Intel, az AMD és az NV saját rendszere is. Egy bugot viszont csak akkor lehet javítani, ha észre is veszed, tehát muszáj olyan profilozóra építened, ami ezeket a problémákat megmutatja. És abból, hogy az AMD-re áttért az Epic a Vulkanra váltás miatt, egy csomót sikerült gyorsítani az Intel és az NVIDIA GPU-in is, mert magának az engine-nek az egyes, esetenként komoly hibáit láthatóvá tette az RGP. És miután már látják a bugot, onnan már nem nehéz azt javítani.
A legtöbb hasonló bugot egyébként régen a konzolokon vették észre, de PC-n nem tudták kimutatni az RGP megjelenése előtt, mert nem volt meg az eszköz, ami látta volna őket. Persze gyanították, hogy ha a konzolon bugos a kód, akkor valószínűleg PC-n is az, csak ellenőrizni nem tudták. Az RGP óta PC-re is van nyomkövetést alkalmazó profilozó, ezért láthatók ezek a mélyen rejtett bugok.
(#47048) Kupszi: Itt nem arról van szó, hogy ki kivel szerződik. Attól, hogy az alap kódot az AMD-vel fejlesztették, még lehet egy rakás szerződést kötni az NV-vel is. De lényeges, hogy a motorok bugjait láthassák, főleg ezekkel az explicit API-kkal. Az Epic például még mindig az NVIDIA partnere, de egyszerűen a Vulkan API-ra jobb Radeonon fejleszteni. Pusztán ettől a döntéstől az NVIDIA hardverek is gyorsabbak lesznek. Ugyanígy az Ubisoftnak van szerződése az AMD-vel, az NV-vel és az Intellel is, viszont a Stadián fejlesztenek szinte mindent. Egyszerűen gyors és olcsó. De ettől még a Watch Dogs: Legion például NV-s, míg az Assassin's Creed Valhalla AMD-s cím lesz. Utóbbiak inkább üzleti döntések, mint technológiaiak, viszont az Ubi mindkét címet a Stadián fejleszti, ami egyszerűen hatékonyabb. Jobb terméket tudnak letenni az asztalra, mert utólag egy csomó mindent lehet optimalizálni, de a mélyen rejtett bugok nagyon fájnak ám, és minden gyártó számára.
(#47049) b. : Természetesen az NV is fejleszti a profilozóját, de azt a bugot, amit az RGP észrevett az UE4-ben, még mindig nem ismeri fel. De lényegesen előrébb járnak már annál, ahol jártak pár éve. Csak eközben az AMD meg csinált egy újabb megoldást, egy tipikus problémára, jelen esetben a memóriamenedzsment teljes profilozására. A legtöbb fejlesztő ma azt csinálja a memóriamenedzsment tekintetében, hogy letöltik a GitHUB-ról az AMD VMA-t vagy D3D12MA-t, és azt módosítgatják. Esetleg nem, az Ubisoft például csak bemásolja a VMA-t, és done. Ezt is lehet csinálni, csak ezeket az AMD nem teljesítménykritikusra tervezte, hanem sokkal inkább általános kompatibilitásra, hogy egyszerű legyen minden motorba integrálni, hogy csak úgy működjön. Viszont annyiféle hibalehetőség van a memóriamenedzsment tekintetében, hogy rohadt nehéz ám felkutatni a memóriaszivárgásokat, stb. Erre hozták a memóriaelemzőt, hogy ha valaki teljesítménykritikus kódban gondolkodik, akkor ne kelljen vakon dolgoznia. És ezek ugyanúgy hasznosak, az NV-nek is, mert a memóriaszivárgásra vonatkozó bugok jellemzően gyártófüggetlenek, minden terméket ugyanúgy érintenek, tehát ha az AMD-vel ki tudják szűrni, akkor az NV GPU-i is gyorsulnak tőle.
(#47050) Jack@l: A konzolokra már jó háromnegyed éve a konzolokon fejlesztenek. A végleges chipdizájnok gyártása is megindult már. Ugye a karácsonyi startra ezeket nagy mennyiségben kell szállítani a nyár végén.
Ha ez a memóriaelemző ilyen egyszerű lenne, de sajnos nem az.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
általánosítva beszélsz a vulkanra való átállásnál arról hogy ez mekkora probléma. De te is tudod hogy a vulkant melyik cég által kitalált alapokra építették és hogy konrétan hány játék épít rá.plusz kiadtak Chronosék tavaly egy gyártófüggetlen profilozót ami hardver függetlenül működik.
hagyjuk ezt az ajnározást kérlek, ez csak nálad működik ilyen egyszerűen, hogy minden fejlesztő mindig az AMD copy paste egyszerű megoldását használja mert ők ilyen dolgokat tesznek le az asztalra és amúgy mindenki erre épít a világon., és hardveresen is fel kell természetesen hozzájuk zárkóznia Nvidának és az Amperevel talán utoléri az iránymutató RDNA1 -t .. jaj istenem.. minek kell ez nekem...
és látod ezek a legendák szülik az ilyen hozzászólásokat, kialakítva a célt és a követő tábort ugye : [link]
[link]
és innentől meg gyomorforgató az egész agymosás.[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
Nem különösebben lényeges az, hogy a Vulkan alapja a Mantle, és az sem, hogy a DirectX 12 is ennek a prototípusából építkezik. Ez tulajdonképpen csak az AMD-nek hasznos, mert úgy építették fel a driverüket, hogy van egy PAL rétegük, és az explicit API-k támogatását egy abba bekötött ICD rétegből oldják meg. Tehát a Radeon Software-ben mindegyik explicit API ugyanazt a PAL meghajtóimplementációt használja, a különbségeket egy ICD réteg hidalja át, ahol az egyes API-k specifikációi le vannak kezelve. Emiatt tudtak anno nagyon gyorsan teljes támogatást adni a DirectX 12-re és a Vulkan API-ra, mert a PAL már meg volt írva a Mantle-re, és annyit csináltak csak, hogy "behidazták" rá a két új API-t. Az Intel és az NVIDIA lassabban reagált ezekre, mert nem volt előre megírva semmijük, a nulláról csinálták. A DirectX 12-t például az NVIDIA egyszer újra is kezdte, míg a Vulkan API-t nagyon sokáig OpenGL alól hívogatták. Azóta lassan kialakult már a megfelelő támogatás, így a programozó vagy a felhasználó számára ez az eglsz mindegy. A PAL tehát csak az AMD-nek segít abban, hogy rendkívül kevés erőforrásból kínáljanak meghajtóimplementációt a Vulkan és a DirectX 12 API-kra is, mert gyakorlatilag egy teljesítménykritikus réteget fejlesztenek a motorháztető alatt. Az sem baj amúgy, hogy az NVIDIA és az Intel a Vulkan és a DirectX 12 API-ra teljesen különálló implementációkat ír. Ugyanúgy működnek, csak költségesebb a fenntartása, mert két teljesítménykritikus meghajtóréteghez két különálló csapat kell. Az AMD azért tud például előállni olyan dolgokkal, mint a D3D12MA vagy a VMA, mert van egy rakás lekötetlen erőforrásuk. Egyszerűen jóval kevesebb rendszerprogramozóval kínálnak Vulkan és DirectX 12 támogatást, így a megmaradt embereket különböző side projektekre rakhatják. Az NV-nek és az Intelnek szüksége van az emberekre, mert amíg az AMD-nek minden PAL-ban végzett módosítás automatikus előnyt jelent minden ebbe bekötött API-n, addig az NV és az Intel külön implementációkat írt, és ha mondjuk a Vulkan implementáción hajtanak végre fejlesztést, akkor abból semmit sem nyernek a DirectX 12-es programok, és fordítva. Valószínűleg egyébként már többször is átfutott az Intel és az NV rendszerprogramozóinak agyán is, hogy az AMD-hez hasonlóan be kellene rétegezniük a drivert, mert végeredményben olcsóbb és gyorsabb lesz az egész, de annyira benne van már a piac az explicit API-kban, hogy egy nulláról történű újraírás problémákat is generálna. Legutoljára ilyet az AMD csinált, amikor 2009-re újraírták az OpenGL implementációjukat. Az ugyan veszettül gyors lett, de elpazaroltak rá egy rakás erőforrást, és valós előnyt nem hozott. Tehát a teljes újraírás az reális mondjuk egy API élettartamának az elején, az NV gyorsan be is vállalta anno a DirectX 12-re, de amikor már benne vagy a lecsóban, akkor jobb a meglévő kódbázist fejleszteni.
Profilozója majdnem mindenkinek van. Az fontos, hogy a Khronos Group gondol a problémára, mert az a helyzet, hogy a Microsoft egyik előnye a PIX, tehát arra is választ kell adni, de nem azért csinálják ezt, mert az Intel, az AMD és az NVIDIA nem tudja megoldani, hanem pont az ultramobil piacra dolgozó cégekért, amelyekre sokkal nehezebb fejleszteni, egyszerűen nem állnak ott a felkínált fejlesztőeszközök minőségében, mint az Intel, AMD és NVIDIA. De ettől a Khronos Group nem oldja meg azokat a problémákat, amely a mélyen rejtett bugokra vonatkozik. Ezeket alapvetően az RGP azért látja, mert úgynevezett hardveres nyomkövetést alkalmaz. A Radeonokba, elsődlegesen a konzolok miatt van beépítve pár extra regiszter és pár extra erőforrás arra, hogy a hardver a saját működését nyomon tudja követni. Egyszerűen meg tudja mondani egy külső alkalmazásnak, hogy a hardveren belül pontosan mi történt. Ezt a külső alkalmazás, jelen esetben az RGP összegyűjti, és készít belőle egy profilt, hogy látható legyen a fejlesztőnek mi történt a hardverben. A legtöbb profilozó nem így működik, hanem teljesítményszámlálókkal operál, ilyen a Khronos Group sajátja is. Ez ugyan nem rossz, de nagyon sok hardveres tényező rejtve marad. A hardveres nyomkövetést egyébként még a Microsoft kérte az Xbox One-hoz, míg a PS4 csak úgy megkapta, mert nem érdemes áttervezni a rendszert pár extra regiszter miatt, és a GCN2-től kezdve a PC-s Radeonok is megkapják. Ilyet egyébként bárki csinálhat, nem annyira nehéz, csak korábban a PC-n annyira nem foglalkoztak a hardverek működésének olyan mély elemzésével, ami korábban ezt szükségessé tette volna. Persze az explicit API-k miatt változnak az idők, illetve régen annyira részletes dokumentációt sem kaptak a GPU-k. Nyilván mindenki tudta, hogy az egyes motorokban van egy rakás bug, csak aránytalanul nagy költségnek gondolták ezek felkutatását és javítását. Mára egy picit változott a környezet, és elkezdtünk menni abban az irányba, hogy ha bizonyos, teljesítményvesztést okozó bugokat nem is javítanak, legalább tudjanak róla.
A D3D12MA-t és VMA-t használják sokan. Ezeket az AMD direkt erre írta, sőt, a VMA-ba már az Intel is írt kódot. Nyílt forráskódú, megtehetik, voltak olyan részei, amelyek az Intel IGP-kre nem működtek optimálisan, így kiegészítették azt. A lényeg itt az, hogy a memóriamenedzsment az explicit API-kkal átkerült a program oldalára, tehát effektíve a fejlesztő írja meg azt, ami korábban a grafikus kernel driverben volt. Ez egyrészt jó, mert sokkal gyorsabb lehet egy alkalmazás, másrészt rossz, mert amellett, hogy ezt igénylik az új API-k, rohadtul nem volt egy olyan fejlesztőkörnyezet sem, amely megmutatta volna, hogy mitől memory leakes a kód. Egy csomóan érezték, hogy az a menedzsment, de nem tudták
megtalálni az okát, régen erről beszéltek is a Hitman fejlesztői, és mivel nem tudták javítani, így együtt éltek a problémával. Ezekre jött a D3D12MA és VMA, amelyek garantáltan működnek, tehát egy fejlesztő, ha problémás kódot ír, akkor már az említett headerek bemásolásával tud azon javítani. Viszont ez ugye nem teljesítménykritikus, mert általánosan kompatibilisnek kell lennie a motorokkal, így készült egy memóriaelemző is az idei évre. Na azzal már megkereshetők a memory leaket okozó kódrészletek, és javíthatók.(#47054) morgyi: Ha a gépigényt akarod növelni, akkor azt meg lehet oldani bugos kód nélkül is. A bugok megtalálása és javítása minden szereplő számára elsődleges tényező.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jacek
veterán
válasz
#32839680
#47056
üzenetére
Biztos vannak anomáliák, de én ezt már ilyen mantrának érzem, ilyen ultimate érv ha elfogy minden "szar a driver"
Mondom ezt 5700XT tulajként, 2080S-t váltott.
Egy problémám volt nem jegyezte meg az egyedi venti profilom 2x megpróbáltam azóta megy AB-val az mindig fent van annyi... jöhet a BigNavi -
Abu85
HÁZIGAZDA
válasz
#32839680
#47058
üzenetére
Kb. ezermilliárd dolog okozhat filmnézés közben véletlenszerű összeomlást. A grafikus driver általában a legritkábban, mert az nincs is igazán használva ilyenkor. Egy fixfunkciós hardveres blokkhoz van továbbítva a feldolgozásra váró adatfolyam. Ez nagyrészt OS-be épített futószalagokon keresztül működik.
A képi hibák hardveres problémákra is utalhatnak. Ha csak egy bizonyos ponton jön elő, akkor lehet a meghajtótól, de ha általánosan, akkor a hardvert is figyelembe kell venni. Szóval a képi hiba önmagában nem jelent semmit. A részletek itt a fontosak.
A Google 692 millió találatot ad a random black screen-re. Tudod miért? Mert ha valami történik a gépen belül, akkor elmehet a kép, azaz fekete képernyőhöz vezet. Ez lehet a grafikus meghajtó hibája, de lehet ezernyi más dolog, és a kettőt nem tudod egymástól megkülönböztetni, mert az eredménye ugyanúgy fekete képernyő. Ezért mondják azt a support részlegnél, hogy a részletek a fontosak, mert a gépen található összes komponens okozhat fekete képernyőt, tehát nem biztos, hogy pont az egy szem grafikus meghajtó az oka. Ez a legnagyobb probléma az efféle hibák felderítésénél, mert a user tényleg csak azt látja, hogy elmegy a kép, de valójában fingja sincs, hogy mitől, és sajnos a userek 99,9%-a azt se tudja megnézni, hogy melyik komponens okozta a rendszerhibát az eseménynaplóban. Emiatt találsz rá a Google-ben 692 millió találatot, kis túlzással minden komolyabb összeomláshoz vezető hibának az az eredménye, hogy elmegy a kép.
A memória-órajel fixálása több kijelző mellett nem bug. Azért van így beállítva, mert egy kijelzőre megoldható a memória-órajel váltása anélkül, hogy a kijelző ne menjen el egy pillanatra, de több kijelzőre nem. Sokszor az órajelváltás azt eredményezi, hogy elfeketedik a kijelző, majd visszajön. Ezért nincs órajelállítás.
A legstabilabb a 20.4.2-es. A 20.5.1-gyel igazából az a gond, hogy nem tudni, hogy mennyi hiba varrható az új Windows frissítés nyakába. Az is tele van sajnos buggal. Ezek egy része egyébként kapcsolódhat a driverek WDDM 2.7-es implementációjához.
[ 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
#32839680
#47061
üzenetére
Mármint egy olyan bejegyzés, hogy némelyik felhasználó még mindig jelzi, de ugye ezzel sokat nem tudnak mit kezdeni. A korábbi black screen bugot azért sikerült javítani, mert a meghajtó okozta, de azóta nem igazán tudnak semmit sem reprodukálni. Ahogy írtam, ezekkel a black screen bugokkal mindig az a baj, hogy akármelyik komponens okozhatja, és az eredménye ugyanúgy az, hogy elmegy a kijelzőn a kép. Kb. olyan, mint a Kernel Power 41 hiba a Windows operációs rendszeren belül. Az oka lehet akármi, táp, vinyó, memória, proci, alaplap, stb., és a user csak annyit lát belőle elfeketedett a kijelzője, mert leállt a rendszer.
Az Edge böngészővel kapcsolatban van egy ilyen ismert bug, de az is csak a többkijelzős konfigokra vonatkozik.
A Windows frissítések mindig ilyenek. Én ezek miatt sosem frissítek azonnal, hanem csak három hónap múlva. Az MS-nél is olyan durva hibák vannak felsorolva, hogy tudnak róla, hogy jobb ezzel várni. Különösebb hátrányod ebből nem lesz, mert úgy sem szokták azonnal kihasználni az alkalmazások az új Windows 10 verziók frissítéseit.
A memóriára lehet fejleszteni hasonló dolgokat, de a lényeg, hogy ez hardveres tényező. Ha engedik, akkor villogni fog a kijelző. Amiért nem nagyon törődnek ennek a fejlesztésével, hogy a memóriák relatíve kis fogyasztók maradtak. Tehát egy többmonitoros idle konfiggal 6-8 wattot, ha nyersz, HBM2-vel 1 wattos se, miközben az üzemeltetése egy ilyen hardveres rendszernek több kijelző mellett eléggé bonyolult.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Ez már kezd kínos lenni..
Komolyan bennem ezért alakult ki a zöld kötődés, neked köszönhetem mester
Minek mosdatod őket ebbe is, mindkét gyártónál vannak hibák, kész. navinál kicsit több volt ősszel, ott sem midnekinél sőt van akináél hibátlan nem egy két ember...most már jobb a helyzet általánosan , ennyi. hagyhatnád néha folyni ezeket a topikokat a maguk medrében...#47065 : nincs ezzel gond ha ugyan úgy kiállnál néha nvida vagy Intel topikban is azok mellett a gyártók mellet ,esetleg néha leírnád hogy milyen előrelátó fejlesztéseket hajtottak végre és jó lenne ha másik cégek is ( igen a nagy Ő is ) néha arra lépne) ilyet nem láttam még tőled, mondjuk más környezetben leírva, csak itt.
általában ott azokat olvasom miért nem jó ez és az a fejlesztés és éppen mit akarnak lenyúlni/ miért nem igazán előrelépés, miért is nem igazán fontos vagy miért is nem igazán jól oldották mert mert / milyen lemaradásban vannak tőle.. a nagy Ő-től
Mintha a valóság és a látott dolgok két dimenzióba történnek. Most hogy végiggondoltam te nem egy demagorgon vagy ? Vigyázz a nyálkás átjárókkal [ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
Ez nem kötekedés. A black screen sokszor a meghajtó nyakába van varrva, de valójában ritkán van köze hozzá. A Google-ön le tudod keresni, hogy 136 milliószor van ez említve az NV-vel, és nagyjából hasonló mennyiségben, 130 milliószor az AMD-vel. A probléma az, hogy alapvetően minden komponenshibánál fekete képernyőt kap a user, és mi van a képernyőre kötve közvetlenül? Igen, a GPU. Tehát sokan ehhez a komponenshez kötik a problémát. Pedig okozhatja ezernyi más komponens is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
amikor az ember VGA-t cserél és megjavul sok dolog, akkor nem igazán gyanakszik másra vagy esetleg rá 2 hónapra jön egy driver és megjavul a dolog.
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
válasz
#32839680
#47066
üzenetére
A BSOD abból a szempontból kellemesebb, hogy az eseménynapló konkrétan leírja, hogy melyik modul az oka. Tudod az idejét a hibának, és meg kell nézni, hogy mitől van. A gyanakvással nem mész semmire. Én mindig is általánosan javasoltam, hogy ha van egy kékhalálja, akkor az első dolga legyen utána felütni az eseménynaplót, és megnézni az okát. Ezeket a rendszer kritikus leállásként jelzi. És akkor találgatni sem kell, kerek-perec le van írva, hogy mitől van. Sajnos nagyon sokan nem veszik erre a fáradtságot, talán nem akarnak pazarolni a probléma felderítésére négy égérklikket. Számukra nem javaslom a PC-t.
(#47067) b. : Nem kell azért hardvert cserélni, hogy kiderüljenek az egyes problémák okai. Erre van a Windowsban az eseménynapló. Alapértelmezett beállítással igen hosszú időszakra rögzíti, hogy mi történt. Elég megkeresni a kritikus hibákat, mert azok számítanak. A többi dolog nem igazán lényeges. A találgatások helyett én mindenképpen a célzott problémaelemzést javaslom. Sokkal hatékonyabb. Nem véletlenül vannak ezek a szervizfolyamatok beépítve az operációs rendszerbe.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Busterftw
veterán
Persze hogy van ilyen is. Több ezer felhasználónak semmi gondja.
Ettől még vannak gondok.
A 3 év alatt nekem se volt egy Windows 10 frissítéssel problémám. De tudom hogy komoly gondok vannak és milliókat érint a probléma. Tele vele az internet, a patch notes, ahogy a írnak mindenhol a Navi gondokról.[ Szerkesztve ]
-
#47074
ƵøŁĭ
veterán
Petykemano
#47073
ƵøŁĭ
veterán
válasz
Petykemano
#47073
üzenetére
Értem. 5600xt és társait akkor nem vennék ha jönne ebbe a szegmensbe is új.
[ Szerkesztve ]
(ง'̀-'́)ง(ง'̀-'́)ง
-
#47079
Televan74
nagyúr
Petykemano
#47078
Televan74
nagyúr
válasz
Petykemano
#47078
üzenetére
Sajnos ez igaz!
Több helyen olvastam hogy csak a drágább Navik kapják meg a Ray Tracing támogatás. Valós lenne ez? Milyen érték határ fölött kell gondolkodni? 150.000 Ft vagy még magasabb összegben?
Amikor nincs remény! Jusson eszedbe nincs isten, csak én!
-
#47081
Alogonomus
őstag
Pkc83
#47080
Alogonomus
őstag
AMD megvalósításában elvileg sokkal hatékonyabb lesz a raytracing, mert nem nyers erőből akarják majd megoldani. Aztán persze majd kiderül minden ősszel.
A fontosabb kérdés viszont szerintem az, hogy egyáltalán elért-e már oda a világ, hogy értelme lenne dedikált hardveres raytracing egységet tervezni egy 300 dolláros termékbe is, amivel az csak (szükségtelenül?) drágulna. Egyszerűbb szoftveres eredetű raytracing-imitálás már sok játékban egyébként is elérhető, komoly szintű raytracing pedig majd az új konzolokkal fog berobbanni, de az még nem idén lesz, PC-re pedig még annál is sokkal később érkezhet. -
#47082
Pkc83
őstag
Alogonomus
#47081
Pkc83
őstag
válasz
Alogonomus
#47081
üzenetére
Igen , sokan gondolják azt , hogy majd a kisebb gyártástechnológia
miatt olcsóbbak lesznek a vga-k de a valóság nem ezt mutatja. sőt..
Még csak nem is egyenesen arányosan drágulnak a teljesítményükhöz képest.
Tehát ha lesz Rt az "olcsóbb" vga-kon is akkor azok már nem is lesznek
annyira olcsók. -
#47083
gejala
őstag
Alogonomus
#47081
gejala
őstag
válasz
Alogonomus
#47081
üzenetére
"AMD megvalósításában elvileg sokkal hatékonyabb lesz a raytracing, mert nem nyers erőből akarják majd megoldani."
Akkor az bukta lesz. RT-nek az a lényege, hogy brutál számításigényes, cserébe fotorealisztkus végeredményre képes. Ha elkezdesz csalni a sugarakkal, akkor gyorsan a raszterizálásnál kötsz ki. Itt legfeljebb annyit lehet trükközni, hogy kicsit okoskodnak a távolságokkal játék szinten (főleg open worldben), mert különben megint ott tartunk, hogy a szobából hiányzik az árnyékok fele.AMD $500 konzolokba hoz RT hardvert. Ha akarják, azt a szintet ki tudják adni PC-n is $300-350 kategóriában.
"komoly szintű raytracing pedig majd az új konzolokkal fog berobbanni, de az még nem idén lesz, PC-re pedig még annál is sokkal később érkezhet."
Jövőre már futószalagon jönnek majd RT játékok konzolra, miközben PC-re nem lesz újabb gen 2022 előtt. Tehát az idei szériának kell majd ezeket is jól vinnie. Amivel szerintem nem is lesz gond, hiszen Ampere esetén 4x gyorsulás várható RT-ben Turinghoz képest + inline RT-re váltás.
Ha meg 2022-ben jön még egy reális 2,5x gyorsulás, azzal már 10x gyorsabb lenne Turingnál, ami simán jó.[ Szerkesztve ]
-
#47084
Busterftw
veterán
Petykemano
#47078
Busterftw
veterán
válasz
Petykemano
#47078
üzenetére
Inkabb lett volna 5600X, a "refresh" meg XT, mint most a prociknal.
Televan
A vallalhato sebessegu RT 2060 Supernel kezdodik (1080p), ami epp 150k.
Max ugy lesz olcsobb, hogy az Ampere utan valogatsz az olcsobb 2XXX szeriabol.[ Szerkesztve ]
-
#47085
Petykemano
veterán
Busterftw
#47084
Petykemano
veterán
válasz
Busterftw
#47084
üzenetére
A vállalható sebességű RT nem azért kezdődik jelenleg a 2060S-nél, mert az RT a jelenlegi Turing szérián nagy performance hittel jár? (Amit persze próbálnak DLSS-sel kompenzálni)
De ha a nexgen RT (függetlenül attól, hogy az AMD vagy nvidia és hogy milyen megoldással) kisebb performance hit-et eredményez, akkor a jelenlegi 2060S tiernél alsóbb tier is futtathat értelmesen RT-t.
Elvileg.Ez azt is jelenti, hogy egyáltalán nem biztos, hogy RT szempontjából jobban jársz majd egy használt 2060S-sel, mert lehet, hogy azt az RT teljesítmény egy új, alacsonyabb tier kártya is tudja majd. Olcsóbb persze nem biztos, hogy lesz, mint a használt.
Találgatunk, aztán majd úgyis kiderül..
-
Yutani
nagyúr
-
#47087
Jack@l
veterán
Petykemano
#47085
Jack@l
veterán
válasz
Petykemano
#47085
üzenetére
Semmivel nem lesze kissebb performance hit, az új inline api csak arra jó hogy butább RT-t lehessen egyeszerűbben leprogramozni. Silányabb minőséggel fog (talán) jobban futni.
Direkt a konozlok miatt kellett az "újítás".[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
#47088
Alogonomus
őstag
gejala
#47083
Alogonomus
őstag
válasz
gejala
#47083
üzenetére
A konzolok ára egyáltalán nem a bekerülési költségüktől függ, hanem attól, hogy mennyi pénzt hajlandóak az emberek fizetni értük. Sony és MS is bőven veszíteni fog a konzolokon, de a játékokkal majd visszatermelődik a meghitelezett veszteség.
2022-ig még elég sok idő van. Amint elkezdenek masszív mennyiségben érkezni az RT 1.1 játékok, akkor bőven elég lesz bevezetnie mind a két gyártónak egy altípust a friss architektúrájához, amivel olcsóbb RT kártyákat tud kiadni az addigra már jobban kiforrott technológiához. A közeli jövőben DXR 1.1 játék nem jön, a jelenlegi 1.0 alapján létező pár játék, plusz a Cyberpunk pedig mindenképpen erős - ezért drága - kártyát igényel.
-
#47089
gejala
őstag
Alogonomus
#47088
gejala
őstag
válasz
Alogonomus
#47088
üzenetére
"A konzolok ára egyáltalán nem a bekerülési költségüktől függ, hanem attól, hogy mennyi pénzt hajlandóak az emberek fizetni értük."
Ez a PC GPU-kra is igaz. Nem sokan fizetnének konzolhoz képest +20% előnyért 2-3x árat PC-n.Igazából nem tudjuk, hogy melyik játék jön RT-vel, mert nem nagyon beszélnek még semmiről, csak pár videót mutogattak játékokról. De CP2077 mellett is van már 8-10 játék, amiről tudunk és biztosan lesznek még új bejelentések is.
-
#47090
Alogonomus
őstag
gejala
#47089
Alogonomus
őstag
válasz
gejala
#47089
üzenetére
"AMD $500 konzolokba hoz RT hardvert. Ha akarják, azt a szintet ki tudják adni PC-n is $300-350 kategóriában."
A PS5-re fejlesztők elbeszélése alapján, a konzolok RT képessége messze meghaladja a 2080Ti RT képességét is. RTX 1.0 < RTX 1.1Azért nem 20% előnyt fognak hozni az ősszel 2-3x áron (1000-1500$) bemutatkozó kártyák. Mondjuk nehéz is összehasonlítani az ősszel érkező konzolokat egy ősszel összerakható DIY számítógéppel. Egy 500$-os konzol viszont biztosan sokkal erősebb lesz, mint egy 500$-ból megépíthető számítógép.
Azért az eléggé nyilvános, hogy milyen RTX játékok érkeznek 1-2 éven belül PC vonalon. [link] RTX azért nem olyan dolog, amit egy indie stúdió csak úgy poénból váratlanul hozzácsap a termékéhez pár hónappal a megjelenés előtt.
-
#47091
gejala
őstag
Alogonomus
#47090
gejala
őstag
válasz
Alogonomus
#47090
üzenetére
"A PS5-re fejlesztők elbeszélése alapján, a konzolok RT képessége messze meghaladja a 2080Ti RT képességét is. RTX 1.0 < RTX 1.1"
Kb minden gyorsabb lesz RT-ben, mint a 2080 Ti. 3060 tutira, 3050 talán nem."RTX azért nem olyan dolog, amit egy indie stúdió csak úgy poénból váratlanul hozzácsap a termékéhez pár hónappal a megjelenés előtt."
Bright Memory-t egy ember fejlesztette és a srác hozzácsapta simán RT támogatást megjelenés előtt.![;]](//cdn.rios.hu/dl/s/v1.gif)
Egyébként RT nem olyan nagy dolog, bármelyik AAA játékba bele lehet tolni pár hónap alatt, ha akarják. Még őszi játékba is belefér, ha most elkezdenek dolgozni rajta. A tavasziakba meg lazán mehet akár mindbe, bőven van még rá idejük.Amihez ennyire előre bejelentették, az csak marketing miatt van, nem azért, mert olyan sok időbe telik.
Illetve eddig az is lassította a munkát, hogy a Turing túl lassú és ezért próbálkozni kell, hogy mit bír még sebességgel. De Ampere már sokkal megengedőbb lesz. Amihez most trükközni kell kicsit Turingon, azt Ampere erőből kinyomja majd trükk nélkül is.[ Szerkesztve ]
-
#47092
b.
félisten
Alogonomus
#47090
válasz
Alogonomus
#47090
üzenetére
mutatnál egy ilyen elbeszélést?
"AMD megvalósításában elvileg sokkal hatékonyabb lesz a raytracing, mert nem nyers erőből akarják majd megoldani. "
Nincs olyan hogy nem nyers erőből . Az RT nek nincs határa. Végtelen erőforrás igényes dolog. Ha elég a hardver az adott feladathoz akkor növelik a részletességet / fényforrásokat / raytracing alapú hangeffekteket, romblható környezetet,és már is kevés újra a hardver. A cél a fotorealisztikus valóság megteremtése és attól még nagyon messze vagyunk...
csalni lehet és kell is különböző erőforrás spóroló megoldásokat kitalálni, de a felszabaduló erőforrást akkor elköltjük újabb fényforrásokra részletesebb textúrákra amik újra növelik az RT erőforrás igényét.A DXr 1.0 ezt tudja amit jelenleg kapsz...
Nem AMD megoldása a DXr 1.1 hanem a Microsofté amit együtt fejlesztettek AMD vel és hihetetlen ,de Nvidiával, mint ahogy a jelenleg elérhető DXr 1.0 sem az Nvidiáé hanem a Microsofté, jó lenne megértened végre így sokadszorra is leírva neked is.Azonos API-n azonos játékokon majd letesztelve kell megnézni mit tudnak a jelenlegi és az érkező kártyák és majd össze kell mérni a jelenleg elérhető 5700 XT-t a jelenleg elérhető 2070 kártyával mondjuk RT terén is,( most is össze lehet) meg majd az Amperet az Új Navival. Jelenleg a nullát hasonlítjuk össze a valamivel és ehhez origónak kiválasztjuk az ismeretlen képességű konzolokat és a koordináta rendszer két tengelyén az Nvidia és a konzol fejlesztők eltérő mértékegységet használnak a konzolok/ VGA RT képességének megállapításához .
Ehhez X: Y hasonlítjuk össze a jelenleg még nem megjelent és nem létező játékok futásának sebességét és minőségét az Inlne RT vel megsózva amiről még annyit sem tudunk mint a többiről..... Azt tudjuk jelenleg egy valódi fejlesztő elbeszélése alapján, hogy a PS5 a Minecraft esetén egy 2080 szintjét ( nem a superét ) tudja kb abszolválni raytracing képességekben a DXr 1.0 alatt. Kérdés mit fog tudni a 2080 és a Ps5 / Xbox a DXR 1.1 alatt és ehhez hogy viszonyulnak az érkező VGA hardverek meg még sok kérdés van ebben a témában amire az idő fog csak válaszolni...[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
válasz
#32839680
#47093
üzenetére
Azért tudnak csodát művelni a Sonynál az exkluzív fejlesztők, csak kérdés mennyire lesz ez általánosan elterjedt akár RT ben, főleg ha ezek nem jönnek át PC re. Náluk van egy két stúdió akik korlátlan idővel és pénzzel rendelkeznek, ők majd biztos kiaknázzák a lehetőségeket a Voxelek/ RT terén.
Xboxnál ugye ott van az, hogy játékaik Kijönnek Windows 10 re ott nem tudnak annyira beleállni a speciális fejlesztésekbe szerintem, bár nem tudom igazából.Helyükben hoznék ki azért pár konzol exkluzív játékot is, Pc megjelenés nélkül. ( ezzel most nagyon magam ellen beszélek)[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
Abu85
HÁZIGAZDA
Oké, szóval aranyos pletykák azok, amelyek szerint alig csökken majd a sebesség az új Radeonon, de én is leírtam, hogy ez nem ilyen egyszerű. [link]
Igen egy csomó helyről hallani, hogy mindössze 10% körüli az RT bekapcsolása az RDNA2-n, de nagyon fontosak a részletek.
A DXR 1.0 eleve egy rendkívül korlátozott dizájn, nincs támogatva benne egy rakás teljesítménykritikus funkció, például az executeindirect, csak memóriapazarló FP32-es vertex formátum van, meg a shaderek meghívása egy bekötési táblára épül, ahol ide-oda kell másolgatni egy csomó adatot az egyes shaderek között, ami rakás felesleges memóriaműveletet jelen. Meg kell csinálni, mert így működik a rendszer, de amúgy rohadt pazarló az egész, mert sokkal jobb megvalósítása is van ugyanannak a problémának.
A DXR 1.1 egy lényeges evolúciós lépcső, amit a Microsoft a gyártókkal közösen dolgozott ki, nem csak az AMD-vel, hanem mindenkivel. Megoldja a tipikus hiányosságokat, van executeindirect, sokkal szabadabb a vertex formátum megválasztása, illetve kidobja a bekötési táblát, és ezzel együtt azt a sok tök felesleges és alapvetően nagyon lassító adatmenedzselést. Itt már az alapvető működés pusztán sokkal nagyobb teljesítményt ad, mint DXR 1.0 mellett, mert maga az inline raytracing jelentősen kevesebb megkötéssel implementálható. Tehát a sugárkövetés már attól sokkal gyorsabb lesz az új hardvereken, hogy DXR 1.1-re implementálják és nem DXR 1.0-ra. És ez nem csak az RDNA2-re vonatkozik, hanem az Ampere-ra is, annak is a hardvere ehhez igazodik, tehát nagyjából ugyanakkora tempóelőnyt szed fel vele az NVIDIA, mint az AMD.
A jövőben a Microsoft az inline raytracinget fogja fejleszteni, egyszerűen ez a gyorsabb megoldása a problémának, de még a DXR 1.1-nek is vannak hiányosságai. Például nem alkalmaz teljesen konfigurálható BVH bejárás. Ennek az oka, hogy a gyártók eltérő BVH adatstruktúra-formátummal dolgoznak, és ezt nem mindenki nyitja meg. Márpedig ha ezt nem ismerik a fejlesztők, akkor nem tudják a korlátjait, nem tudják, hogy hova kell optimalizálni a nagyobb sebességhez. A sugárkövetés jelenleg PlayStation 5-ön a leggyorsabb, de csak azért, mert ez a konzol lehetőséget ad arra, hogy egy compute shaderben egyedi BVH bejárást írjanak a fejlesztők, így egy csomó olyan teljesítménykritikus algoritmus válik megvalósíthatóvá, amire például még a DXR 1.1 sem ad lehetőséget. De végeredményben ez is pusztán egy szoftver, a hardver megismerésével tudod, hogy mit kell kezdeni vele, így pedig nyilván nem nehéz olyan RT effektet csinálni, ami a DXR 1.0-ban megszokottnál nagyságrendekkel gyorsabban fut, miközben ugyanazt az eredményt adja. Szerintem azok az eredmények, amelyeket hallani az RDNA2-ről, a Radeon Rays 4.0 kiegészítésekből származnak, amelyek ugyanúgy megengedik majd PC-n a compute shaderből szabadon konfigurálható BVH bejárást a DirectX Raytracinggel. Az pedig nem újdonság, hogy a hardverek gyorsak tud lenni, ha optimalizálásban lemész a legalacsonyabb szintekig. De ez a sebesség nem ültethető vissza a natúr DXR 1.1-re, pláne nem a sokkal lassabb DXR 1.0-ra.Hosszabb távon a Microsoft dolgozhat azon, hogy szabványosítanak egy BVH adatstruktúra-formátumot. Ma ez azért baj, mert eléggé sok alternatíva van. Az Intel sajátot használ, az NVIDIA is, az AMD is, de legalább a konzolok ugyanazt használják, amelyiket az AMD. Tehát részben van már egy közös pont. Innen az lenne a lényeges, hogy ezt a közös pontot kiterjesszék. Ez részben egy licencelési probléma is, mert itt nem csak az Xbox Series X-ről van szó, hanem a PlayStation 5-ről is, és bizonyos IP-k, amelyek vannak az RDNA2-ben azok a Sony fejlesztései, de az AMD, a Microsoft és a Sony keresztlicencben dolgozik (de részben emiatt zártak a Radeon Rays 4.0 egyes részei, mert nem 100%-ban az AMD megoldása, hanem egy Microsoft-Sony-AMD kooperáció). Na most ezt ki kellene terjeszteni az Intelre és az NVIDIA-ra is, meg még azokra a gyártókra, akik jönnének, tehát meg tudom érteni, hogy jelenleg miért nincs szabadon konfigurálható BVH bejárás a DXR 1.1-ben, de előbb-utóbb itt is megegyeznek majd, mert úgyis erre kell menni az egyes algoritmusok megvalósíthatósága érdekében. Viszont ehhez ugye kell egy licencszerződés, ha az megvan, akkor el kell kezdeni tervezni az új hardvereket, immáron az érkező, egységesített BVH adatstruktúra-formátumra, stb. Szóval ez időben sokáig fog tartani.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
X2N
senior tag
Inkább azon kellene dolgoznia a fejlesztőknek hogy többkártyás rendszereket lehessen hatékonyan használni sugárkövetésre. Ez bevált dolog azoknak akik vga-val renderelnek.
Most a PCie 4.0-val már megvan a sávszél 4db 2080Ti-nak is. Ezek a mostani kártyák kevesek erre, majd ha 1 kártya 50TFlops teljesítményt tud, akkor már lehet realtime sugárkövetésre alkalmas kártyáról beszélni. Aki az új konzoloktól várja a csodát, az csalódni fog. Még ha agyon is optimalizálák itt nincsenek csodák, a brute force megoldás adja a legjobb képet.[ Szerkesztve ]
Launch code for russian nukes: 97 99 116 105 118 97 116 101 32 100 101 97 100 32 104 97 110 100
-
Abu85
HÁZIGAZDA
Offline ez bevált dolog, de a real-time nem ennyire egyszerű. Utóbbinál azért nagyobb hátrány az adatmásolás per sugár, mint annak az előnye, hogy külön dedikálsz a sugárkövetésre egy GPU-t.
Ami működőképes lehet az a teljes feldolgozás felosztása, például AFR-rel, vagy SFR-rel, de leginkább valami scissor modellel. Vagy írnak egy olyan motort, ahol az árnyalás függetlenített a leképezéstől, így pedig az árnyalási munkák leoszthatók egy csomó GPU-ra, és lenne egy szem fő GPU, ami csak a leképezést csinálja.
A DXR 1.0, a DXR 1.1, illetve a Sony megoldása is brute force. A különbség az, hogy mennyire pazarlóan vagy hatékonyan bánik a rendelkezésre álló hardverrel. De az eredményük ugyanaz. Itt gondolj arra, hogy a megjelenített kép tekintetében a DirectX 11 is ugyanazt csinálta, de eközben a DirectX 12 többszálú optimalizálásával egy csomó rajzolási parancsra levetítve sokkal gyorsabb. Mindkettő API brute force, csak az egyik pazarló, míg a másik hatékony. A DXR 1.0 és a DXR 1.1 esetében nem mindegy, hogy például a DXR 1.1-gyel már amikor találatkor, vagy találat nélkül a függvény visszatér, akkor helyből ott a kontextus struktúrája a shaderben. Nem kell azt bekötni, hogy egyáltalán folytatni lehessen a számítást a hit vagy miss shaderrel. Egy csomó adatmozgást megszüntetsz ezzel a lapkán belül, miközben a számítás része ugyanaz marad. Ha ez nem számítana, nem nyomtak volna egy ekkora resetet az inline raytracinggel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
Realtime renderelnek tobb kartyaval mar evek ota... Offline meg realtime k0yt csak a renderelesi ido es minoseg az elteres.
[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
Mondom ezt 5700XT tulajként, 2080S-t váltott.
Mintha a valóság és a látott dolgok két dimenzióba történnek. Most hogy végiggondoltam te nem egy demagorgon vagy ? Vigyázz a nyálkás átjárókkal 
![;]](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 AMD é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.
- Azonnali VGA-s kérdések órája
- Windows 11
- Magga: PLEX: multimédia az egész lakásban
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Facebook és Messenger
- Autós topik
- Mozilla Firefox
- HP notebook topic
- Azonnali informatikai kérdések órája
- A Gigabyte is visszaveszi alaplapjainak alapértelmezett tuningját
- További aktív témák...