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ő.

Mármint miben lenne gyorsabb?

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.

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 ]

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 ]

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

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 ]

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.