-
IT café
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
Driver téren abban járnak jól ezzel, hogy sokkal hatékonyabban fejlesztik magát a drivert az explicit API-kra. De ez nem csak ebből ered, hanem abból is, hogy az Intellel és az NV-vel ellentétben az AMD teljesen másképp írja meg a D3D12 és a Vulkan implementációt.
Például elég nagy különbség, hogy az Intelnek és az NV-nek külön rétege van mindegyik explicit API-ra. Tehát 100%-ban külön kódbázis a D3D12 és a Vulkan. Az AMD-nél nem így van. Ott egy közös réteg van, ami a PAL. Minden egyes explicit API erre a rétegre van húzva egy ICD-vel. Tehát a közös PAL-on fut a D3D12, a Vulkan és a Mantle ICD is. Emiatt az AMD nagyjából feleakkora erőforrás befektetésével is gyorsabban fejleszt, mint az NV és az Intel az explicit API-k támogatása kapcsán. Ezért van az, hogy nemhogy szűkülne az olló például az overhead kapcsán, hanem egyre csak nyílik szét.
Az Intelnél valószínűleg erre látunk majd megoldást a Battlemage bemutatkozásával, mert ők már javában dolgoznak azon, hogy összevonják az explicit API-s fejlesztési modellt úgy, ahogy az AMD csinálja. Raja kardoskodott nagyon, hogy inkább most kell váltani, mint később, mert soha az életben nem érik utol a Radeon meghajtók teljesítményét, ha nem térnek át ugyanarra a fejlesztési modellre. Most ugye ez az iparági mérce.
Ez az oka annak, hogy amíg az Intel és az NV az erőforrásaik közel 100%-át belenyomja a D3D12/Vulkan implementációkba (sőt, az Intel a D3D9-től konkrétan meg is vonta az erőforrást), addig az AMD annyi szabad kapacitása van, hogy újraírták mára a D3D11 és az OpenGL implementációjukat. Nem tudják hova rakni a szabad programozóikat, mert alig kell dolgozniuk az explicit API-s meghajtókon, miközben azok overheadben kb. utolérhetetlennek tűnnek.Nézd meg például a Plague Tale: Requiem esetében a meghajtók többletterhelését. [link] - És az AMD ezt a játékot nem is profilozta fel. Sose jött hozzá profilváltás, az egész az általános profilról megy. Mindez nagyrészt annak köszönhető, hogy a fejlesztők D3D12MA-t használnak, illetve az Asobo használta először az RPS-t, igaz nem a publikus verziót, hanem egy nagyon előzetes kiadást, amihez nyilván fejlesztőként hozzá tudtak férni. És ilyen körülmények mellett az Unreal Engine 4 működése annyira megváltozott, hogy az AMD-nek nem is kell rá dolgoznia a driver oldaláról, ami persze nagyrészt annak köszönhető, hogy a menedzsment kód, amit a játék használ 100%-ban az AMD-től származik. Gyakorlatilag ez felfogható úgy, hogy az AMD írta meg a játék teljesítménykritikus részeit, csak nem specifikusan, hanem egy általánosra fejlesztett kóddal.
Ezért akarta az AMD ezt az explicit API-ra való átállást, mert ők nagyon berendezkedtek erre. Tudják, hogy itt nem igazán a driveren múlik az egész, felesleges azt olyan extrém bonyolultra fejleszteni, amilyen bonyolultra csinálja például az NV a nagy overheadet adó emulációs rétegeivel. Csak a humánerőforrást viszi, és hozzáadott sebességet alig kínál, miközben lesz egy nagyon komplex kódod, amit aztán extrém drága fenntartani.
És ugye még reagálni kell arra is, hogy például egy 250 fős Asobo, amelyik nem kis fejlesztő, bár nyilván nem is übernagy, jobbnak érzi azt, hogy másfél év munka helyett egyszerűen elkérje az AMD menedzsment kódjait (vagy letöltse a GitHubról, ha már elérhetők), és azt beépítse a játékba, megspórolva ezzel másfél év optimalizálást, és minimum 10 programozó teljes másfél éves fizetését. Nem véletlen, hogy az Intel is elkezdte a saját dizájnjaira optimalizálni a D3D12MA/VMA kódokat a GitHubon, mert rájöttek, hogy ez olyan spórolást jelent kb. mindenkinek, hogy a jövőben a stúdiók 99%-a így fog dolgozni. Innentől kezdve pedig nekik is arra kell gyúrniuk, hogy a D3D12MA/VMA kódok out-of-box menjenek az Arcokon az általános meghajtóprofillal.Egyébként már programozói szemléletben is nagyon durván eltérnek a cégek explicit API implementációi. Amíg a hagyományos API-k kapcsán ez megegyező volt, addig az explicit API-k esetében az AMD a KISS szemlélettel dolgozik egy jó ideje, míg az NV és az Intel BDUF koncepcióval. Ez is mutatja, hogy mennyire nem volt egyértelmű, hogy mi lesz a jó. Egyébként első nekifutásra a "Big Design Up Front" nagyon is jónak tűnik az explicit API-kra. Olyannyira, hogy az AMD az első Mantle implementációnál is így dolgozott, csak a gyakorlatban rájöttek, hogy mennyire sok bajt okoz, amikor a tervek szintjén pöpecre megdizájnolt koncepciód elkezded leprogramozni, és bezuhan vele egy rakás desing flaw, amire rá kell rakni az erőforrást, hogy javítsd. Lásd az NVIDIA 384.76-os eszközillesztője, ami durván módosult, amikor egy korábban istenkirálynak tűnő rendszerről kiderült, hogy egyben egy durva desing flaw is, és hát utólag rendesen meg kellett kalapálni, hogy relatíve jó legyen. Az ilyen jellegű over-engineeringek jól működtek DirectX 11-gyel, de ritka rosszak explicit API-val. Ide úgy néz ki, hogy a Keep It Simple Stupid az optimális, annak ellenére, hogy szigorúan elméletben tényleg a BDUF tűnik jónak.
[ 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 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.
