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 ]
