Új hozzászólás Aktív témák

• #20782 Abu85 HÁZIGAZDA keIdor #20770

  Új Válasz 2016-08-07 11:04:51 #20782

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz keIdor #20770 üzenetére

  Volt még a Tonga is, illetve a Carrizo variánsok, valamint az Iceland.

  A támogatás és ptimalizálás az explicit API-kban nem olyan, amilyenre gondoltok. Annak ellenére, hogy a hozzáférés a hardverhez sokkal közvetlenebb, még mindig nem annyira alacsony szintű, hogy számításba kelljen venni a GPU-kat. A Mantle részben ilyen volt, de annál egy picit magasabb szintre helyezték a működést a DX12 és a Vulkan API-ban. Tehát effektíve nem annyira lényeges, hogy van GCN1/2/3/4 is, mert azokat DX12/Vulkan alatt el lehet fedni. Az egyetlen kivétel a multi-engine kezelése, amely bizonyos körülmények között finom paraméterezést igényel, de ott sem a GCN1/2/3/4 számít hanem az, hogy mire képesek az ACE-ek, HWS-ek, a GMU-k, vagyis a független parancsmotorok. Nyilván számít, hogy a hardver mennyi független parancslistát kezel, mivel a compute motorokat a driverből kell etetni, míg a grafikai parancslistáról az OS gondoskodik. A driver előtt persze még viszonylag sok lehetőség van arra, hogy egy compute parancsot hova pakol be, de a meghajtók ha tehetik új parancslistába töltik be, és ott már elég nagy különbségek lehetnek. De ugyanakkor az AMD ezért ragaszkodik a GCN2 óta a 64 parancslistához és a 8 különálló parancsmotorhoz, hogy a fejlesztők ezt célozva igen nagy hardverbázist képesek lefedni. A GCN1 ebből persze kevésbé jól profitál a 2 parancslistájával, de működni működik. Rosszabb esetben a driver dönthet úgy, hogy a compute parancsot beküldi az OS grafikai parancslistájába. A GeForce-ok például így csinálják szinte minden DX12-es játékban (kivéve a Pascalt az új Tomb Raiderben).
  Aztán ezt a történetet még bonyolítják azok a lehetőségek, mint a priority flag, ami definiálva van a DX12-n belül. Egy fejlesztő egy compute parancsot jelölhet magas prioritásúnak, és akkor azt a drivernek úgy kell beraknia a független parancslistákba, hogy azonnali végrehajtás történjen. Ugyanakkor itt vannak specifikációs lékek, ugyanis a priority flag mehet közvetlenül az OS grafikai parancslistájába is, vagyis nem kötelező a driverben implementálni ezt a képességet. Az AMD-n kívül nem is implementálta más. Bizonyos programokban ezért van letiltva minden más hardverre az aszinkron compute. Nem állítja be a driver a magas prioritást, ezért berakja az azonnali eredményre kijelölt munkát a sorba, a munka eredményét igénylő számítás pedig csak áll, amíg a parancs lefuttatásra nem kerül. Valószínűleg ezt a kerülőutat a Microsoft szándékosan hagyta benne a specifikációban, hogy kifejezetten rossz "egyszálú" teljesítménnyel rendelkező hardvereknél a gyártóknak ne kelljen erre a gyengeségre kötelezően implementációt készíteni. Szóval a drivernek van jelentősége csak nem annyi, mint régen.

  Aminek sok jelentősége van az a memória vezérlése és a bekötés kialakítása. Na ez már nagyon trükkös. Főleg úgy, hogy a Microsoftnak és a Khronos Groupnak létezik egy ajánlott konstrukciója rá, de a gyártók nem mindenhol értenek azzal egyet. Egyedül az AMD ajánlja pontról-pontra ugyanazt, amit a Microsoft és a Khronos Group. Az Intel a bekötés és erőforrások menedzselésénél egyetért az API-kat szállító konzorciumokkal, de a memória vezérlésénél már nem. Az allokáció tekintetében a VRAM felbontását az MS és a Khronos Group is kicsi szeletekre javasolja, lehetőség szerint a legkisebbekre, ami még hatékony az adott motorral. Ugyanezt írja elő az AMD is. Az Intel pont a nagyobb szeleteket kedveli, ahogy az NVIDIA is. Az NV-nek ez a terület a Vulkan API-val olyannyira problémás, hogy külön hoztak rá egy kiterjesztést, amivel dedikált allokációk alakíthatók ki. Ráadásul a bekötés és erőforrások menedzselésénél sem azt javasolja az NV, amit a Microsoftnak és a Khronos Group, hanem a gyökeres ellentétét. A GeForce-okkal ez működik hatékonyan. Egyébként az NV ajánlott modelljeinek is megvannak a maga hátrányai, lásd az új Tomb Raider DX12-es módját. Nem véletlen, hogy a Microsoftnak és a Khronos Group nem ezeket ajánlja a fejlesztőknek, mert általánosan nem hatékonyak. Máshogy kell kezelni az eltéréseket, és ezek a gyártók közötti ajánlásbeli eltérések sokkal nagyobb problémát fognak okozni, mint a gyártón belüli apróbb különbségek.

Új hozzászólás Aktív témák