AMD Radeon™ találgatós topik - Videokártyák fórum

Hirdetés

üzenetek

hozzászólások


morgyi
(veterán)
Blog

Szerintem azért pont számít hogy a konzolokban AMD van. A középkategóriás kártyák elég jó teljesítményt nyújtanak. Nincs egy ideje erős kártyájuk. Az Nvidia erősebb ennyi. Szerintem kár ebbe belekeverni azt hogy NV-re jobban optimalizálnak. Fontosak a szoftveres újítások, de a fejlesztői oldalon meg ott az idő meg a pénz. Csak 1-2 stúdiónak van erre ideje és pénze.
A Raytracing meg a DXR miatt fog jobban terjedni, meg amiatt hogy az új címek direktben célozzák a PS5-öt és az Xbox Series X-et.
Két éve van RTX kártya. A raytracinges címeket meg egy kezemen meg tudom számolni. Mire elterjed addigra meg az AMD is tud majd hardveres raytracinget. Ebben pont nincsenek lemaradva.
Ez ugyanaz a kategória mint az AMD jövőbemutató featurejei. Mire elkezdett terjedni addigra az NV is támogatta.

[ Szerkesztve ]


Abu85
(HÁZIGAZDA)
Blog

Éppen az a helyzet, hogy már nem NV van a játékfejlesztők gépeiben. GeForce-szal sokkal nehezebb explicit API-kra fejleszteni. Nincsenek olyan jó fejlesztőeszközök hozzájuk. Például semmi esélyed megállapítani a memóriamenedzsmentedben egy memory leak okát az NVIDIA GPU-in, nincs semmilyen tool, ami neked lemonitorozza, hogy a memória éppen hogyan néz ki. Radeonon van, és emiatt használnak ma már Radeonokat a játékfejlesztéshez. GeForce-on maximum annyit tehetsz, ha nem jó a memóriamenedzsmented, hogy lemásolod az AMD-nek a D3D12MA/VMA-ját (egy csomóan ezt csinálják manapság), mert memóriafigyelő nélkül monitorozni a sajátod nem tudod.

[ Szerkesztve ]


Yutani
(nagyúr)
Blog

Szóval azt állítod, hogy a dGPU piac 70%-át uraló Nvidia kártyái helyett az AMD eszközeivel dolgoznak a játékfejlesztő cégek?

Tudod, hogy most mi fog következni... :DDD


Petykemano
(addikt)

Természetesen, kivéve azokat, akiket lefizetnek egy 2kg-os téglalap alakú fejlesztőeszközzel.


Petykemano
(addikt)

Volt cikk (PH!) a GPU hardveres ütemezőről? Most nem találom

De emlékszem, Abu azt mondta, hogy ha a kaveri IGP-n futna az ütemező, akkor gyorsabb lenne, mint az i7.

az AdoredTV podcastban beszéltek róla, hogy volt teszt, de végülis nem egyértelmű a jósága, azt mondták, hogy ahol cpu limit van, ott volt előnye, ahol gpu limit, ott akár hátrányt is jelent.

Viszont nem emlékszem olyan tesztre, ahol kifejezetten IGP-n futott volna az ütemező.


paprobert
(aktív tag)
Blog

Mármint miben lenne gyorsabb?


Petykemano
(addikt)

Azonos videokártyával képes lenne megegyező, vagy nagyobb fps-t elérni annak ellenére, hogy a cpu rész gyengébb.


Kupszi
(tag)

Neharagudj de ezt egyszerűen nem tudom elhinni.
Volt róla szó az Ubinál hogy majd most AMD felé haladnak, de ez az infó abba is maradt. Metro féle gammák biztos megmaradnak, Unreal motor játékok szintén zenészek, na és itt az év várva várt játéka a Cyberpunk. Aztán Dice is beadta derekát a pénznek és a BFV és valamint a BF6 is beáált ezalá, a COD szériáról ne is beszéljünk, de vegyük a méltán híres Esport gammákat ,(Rockstar games) vagy Fornite vagy PubG-t. A két utolsót azért érdemes megemlíteni, mert óriási a játszó közönsége. Az nvidia mindig oda dugja be a pénzét ahol tuti berobban.
Személy szerint nem preferálom az nvidiát, sőt elég mocskos módon játszik a piacon, de be kell lássuk eszméletlen jól csinálja. Még így is hogy a konzolokat az AMD zsebelte be.


b.
(nagyúr)
Blog

ezt már megoldották van nvidás monitorozó már, te is írtál róla cikket.


Jack@l
(veterán)

Ok, persze, azt mivel fejlesztenek DXR-t a nextgen játékokhoz? Mert amdvel tuti nem egy ideig...
Erős kétségem van hogy nincs egy monitorozójuk amivel lehet követni a mem felhasználást. :D


Abu85
(HÁZIGAZDA)
Blog

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 ]


morgyi
(veterán)
Blog

Jól meg lett szivatva az NV meg az Intel akkor. Pedig mennyivel jobb lett volna nekik ha a leglátványosabb UE4 címek csúcskártyát kérnek meg csúcs i7-et. Gondolom anno a Crysis 2 város alatt hullámzó tengere is így maradt bent "véletlenül". Cserébe kérte is a vasat, lehetett a kasszákhoz fáradni a minőség igényes gamereknek.


b.
(nagyúr)
Blog

á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 ]


morgyi
(veterán)
Blog

Volt ám a hsz-emben irónia is masszívan ha ez nem esett volna le. Amúgy meg el tudom képzelni hogy ezeket az optimalizálatlanságokat sokszor nem is akarják kigyomlálni. El kell adni a hardvert, a gyártóknak is win szituáció ha növekszik a gépigény.
Így is eléggé látszik az árakon, hogy a fullHD kompromisszummentes konfigot annyiért kapod meg mint régen, semmivel nem lett olcsóbb csak lejjebb csúszott közép-alsó közép kategóriába.
Nehéz elhinni ezt az AMD jószolgálati nagykövet dumát. És a Zen3 B450 balhénál is látszik, hogy mihelyst kezdenek nyeregben lenni egyből nem olyan jófejek. Nem cél hogy évekig ellegyél ugyan azzal a vassal mert egyre jobban optimalizáltak a címek PC-re. Arra ott a konzol.

[ Szerkesztve ]


Abu85
(HÁZIGAZDA)
Blog

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 ]


morgyi
(veterán)
Blog

Persze hogy meg lehet oldani, de azért nem az a jellemző hogy a legtöbb game az optimalizáltság szent oltára lenne.

Amúgy meg nem ártana ha az AMD a felszabadult rendszerprogramozói erőforrást a drivereinek stabilitására meg a bugmentesítésére fordítaná. Az RX5000 szériával megjelenés óta van probléma driveres fronton, és gyanítom ez már így is marad, mert ha az RDNA2 megjelenéséig nem javítják utána már nem fogják úgy sem.


Jacek
(őstag)

Biztos vannak anomáliák, de én ezt már ilyen mantrának érzem, ilyen ultimate érv ha elfogy minden "szar a driver" :D 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 :D


morgyi
(veterán)
Blog

Én meg mint 5600XT tulaj szívtam már 1-2 driverrel ami óta megjelent. Aztán időm sincs sok játszani. De volt már Win alatt filmnézés közben random crash, meg képhibák a 20.5-ös driverrel. De a 2004-es win se a világ legstabilabb dolga. De azért sokaknál van random black screen, meg azt sem bírták megoldani hogy visszavegye a memória órajelet több kijelző esetén ha az egyik 60+ Hz-es. És ez jó régóta ismert bug. És ahhoz pont elég hogy idle is elkezdje a ventilátort pörgetni.
A legjobbnak a 19.12-es drivert mondják, csak hát az meg az 5600XT megjelenése előtt volt...


Abu85
(HÁZIGAZDA)
Blog

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 ]


Busterftw
(senior tag)

Lehet mantrának tűnik, de elég megnezni a release notesban, most már eljutottak oda, hogy driverenként nem 15 hibat javítanak, csak 10-et kell, miközben a known issues 20-ról 15-re csökkent.
Aztán itt vagyunk Júliusban.


morgyi
(veterán)
Blog

A Radeon driverek known issues részén hónapról hónapra vannak blackscreen bugok. A böngésző hardveres gyorsítás közbeni crash is ismert bug.
A képi hiba meg annyi volt hogy minden videóra legyen az akár webes vagy offline ami hardveres videógyorsítást használt rákerült egy fátyol amitől kiszürkült az egész.
20.4 vissza megjavult...
Azzal meg nem tudok mit kezdeni hogy az AMD vagy az MS sara-e. Az tuti hogy nem volt ennyi szívás a 2004 előtt.
A memória órajelváltás technológiáját meg úgy látszik az NV-től kellene licenszelni... Mert ott visszaveszi IDLE-re az órajelet, ők nem panaszkodnak. Amúgy nálam is visszaveszi, két kijelzőnél is és fel is kapcsol ha kell. Van akinél meg nem. Meg bizonyos kijelzőfrekvenciáknál visszaveszi. Ez rohadtul BUG... nem pedig feature.

(#47060) Busterftw Egy évvel az 5700XT launch után :C :R

[ Szerkesztve ]


Abu85
(HÁZIGAZDA)
Blog

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 ]


b.
(nagyúr)
Blog

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 :R :DDD
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 :DDD

[ Szerkesztve ]


Jacek
(őstag)

Én meg vagyok az elégedett ügyfél akinek nincs problemja, na bumm ilyen is van.


Abu85
(HÁZIGAZDA)
Blog

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.


morgyi
(veterán)
Blog

Most néztem át az RX5000 topikba: [link]
Mikor felrakod az újabb drivert és addig sosem látott BSOD rendszeres lesz, akkor mire fogja a júzer? A procira?

Ja persze, a memóriával csak épp annyit spórolsz hogy működik a zero fan. Maxra kapcsolt memória órajellel meg elindul a hűtés. Ja rohadtul nem éri meg rá időt áldozni.
Inkább szívjon vele a júzer, állítson be egyedi időzítést és frekvenciát mert akkor még épp működik.
Vagy az user áldoz arra időt hogy legközelebb Nvidiát vegyen. Nem is értem miért nem megy feljebb a részesedés... Remélem azért nem minden AMD-s ember felfogása ilyen.
Amúgy 105k-ért vettem az 5600XT Pulse-t ráadásul az 5700XT több hőcsöves hűtésével. Ennyi pénzért bevállaltam a driveres szopást is. De attól még nem kell védeni.

Eddig a PS4 a legstabilabb AMD cuccom :DDD ;]

[ Szerkesztve ]


b.
(nagyúr)
Blog

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 ]


Abu85
(HÁZIGAZDA)
Blog

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 ]


Petykemano
(addikt)

"Komolyan bennem ezért alakult ki a zöld kötődés, neked köszönhetem mester"

Úúúúú, lehet, hogy abut is az nvidia fizeti?
Vagy az lenne a gond, hogy az AMD nem? :D


morgyi
(veterán)
Blog

Hát ha nem lennénk ilyen kis ország ilyen kis piaccal akkor már Abu rég AMD nagykövet lenne :D


Busterftw
(senior tag)

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 ]

üzenetek