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

• #34376 Abu85 HÁZIGAZDA ->Raizen<- #34374

  Új Válasz 2018-07-04 11:02:00 #34376

  Ú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 ->Raizen<- #34374 üzenetére

  Ez DX12 alatt erősen programfüggő is. A meghajtó csak korlátozott mértékben segíthet. A drivernél elsődlegesen azért volt látható egy időben javulás az NV-nél, mert az AMD DX12 meghajtója máshogy van felépítve. Nagyon röviden arról van szó, hogy a gyártók számára szabad az implementáció kérdésében trükközni. A Microsoftot és a Khronost addig érdekli a dolog, amíg az adott implementáció átmegy a hitelesítési teszten, de arra magasról tesznek, hogy a hardverhez közel a driver mit csinál.

  Az AMD megoldása egy tipikus KISS koncepció, keep it simple, stupid. Maga az explicit implementáció egy közös rétegben valósul meg, amit PAL-nak hívnak. És ez a Mantle óta létezik, azóta fejlesztik, van benne egy rakás pénz, és ami a legfontosabb, kb. 5 év tapasztalat. A Vulkan és a DX12 csak egy ICD-vel van a PAL fölé húzva. Tehát mindkét API esetében az alapréteg ugyanaz, vagyis ha ezt fejlesztik, akkor egyszerre javul a Vulkan és a DX12 meghajtó is. Ezt a rém egyszerű modellt azért alkalmazzák, mert annyira nehézkes a külön reagálni az API-kra, hogy rengeteg erőforrást vinne el a natív megközelítés, de így az erőforrásokat arra fordíthatják, hogy a PAL réteg legyen nagyon gyors.

  Az NV megoldása ma már nem ilyen egyszerű. Régen ők is furcsán közelítették meg ezt, volt amikor a Vulkan API-t az OpenGL alól hívogatták, de a DX12-t is megpróbálták költséghatékonyan beintegrálni, de egyik sem sikerült. A mai meghajtóval már natív Vulkan és natív DX12 támogatás van átlapolásra vonatkozó rétegezés nélkül. Ennek az előnye, hogy tényleg specifikusan lehet az implementációval az API-kra reagálni, viszont hátránya, hogy a sok trükközés miatt egészen bonyolult a kód, és a karbantartása sokszorosan több pénzbe és humánerőforrásba kerül. Emellett ugye a mostani implementációk alig egy évesek, vagyis a tapasztalat alapján beépített teljesítmény is kevés bennük. Ezért tudtak az elmúlt évben sokszor javítani, mert akkor még csak pár hónaposak voltak az implementációk, és könnyű volt sebességet találni. Ahogy telik az idő, ez egyre nehezebb lesz, mert függetlenül attól, hogy kívülről nem látszik, azért a háttérben a kód fejlődik, és bizonyos változásokkal mikromásodperceket nyernek helyenként.

  Az Intel DX12-es megoldása hasonló az NV-hez, de ők a Vulkan esetében csináltak egy érdekes dolgot. Hasonlóan rétegelték az implementációjukat az AMD-hez. Emiatt nagyon érdekes, hogy a DX12 implementációjuk nem annyira erős, de a Vulkannál a mostani kód hihetetlenül jó. Valószínű, hogy a jövőben döntenek majd arról, hogy a DX12-nál megoldják azt, hogy írnak egy kliensoldali modult a Vulkan implementációhoz használt hardverhez közeli rétege fölé. És akkor a DX12 implementációjukkal is áttérnek a KISS-re. Ezzel ugye az a baj, hogy élesben csinálják a váltást, ami egy csomó meglévő programnál hibát generálhat, de valószínűleg a hosszabb távú hatásai megérik. Látva azt, hogy mennyire jól működik a Vulkan driverükben a hardverközeli réteg, egyértelmű, hogy nem éri meg szenvedni a jelenlegi langyoska DX12 implementációjukkal.

  Egyébként nem biztos, hogy az NV-nél jelenleg működne a KISS megoldás. Biztos van oka annak, amiért ők ezt kerülik, annak ellenére is, hogy az AMD-nél általánosan, míg az Intel Vulkan driverénél látványosan jól működik.

  [ 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