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

• #24179 Abu85 HÁZIGAZDA HSM #24167

  Új Válasz 2016-11-19 13:02:05 #24179

  Ú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 HSM #24167 üzenetére

  Ez nem ilyen egyszerű. És ez alapvetően félre van értve.

  A GCN azért tud jól alkalmazkodni ezekhez az explicit API-khoz, mert van a multiprocesszorokon belül egy elég sokat tudó skalár egység. Ilyen nem nagyon szokott lenni a GPU-ban. A CPU-kban alap, de a GPU-kban inkább úgynevezett branch egység van, ami nem tud annyit, mint a GCN-nek a skalár egysége. A legfőbb különbség a konstans puffer és a erőforrásleíró hardver között van. Az AMD nem fixfunkciósat használ ezekből, hanem programozhatót. Ez lehetővé teszi, hogy bármelyik API-hoz tökéletesen alkalmazkodjon az architektúra, és teljesen mindegy, hogy az adott API milyen bekötési modellt ír elő. Egyszerűen azt a modellt leprogramozzák a meghajtóban, és az erőforrásokról az aktuális képet a memóriában tárolhatják. Ezért van az is, hogy az AMD a Mantle, a DirectX 12 és a Vulkan API-ra is ugyanazt a PAL réteget használja a meghajtóban, mert egyszerűen a felszín alatt mindegyik API-t pontosan ugyanúgy kezelik. Erre a PAL rétegre pedig fel van húzva egy ICD réteg, ami az adott API specifikus jellemzői szerint dolgozik. A modell előnye, hogy bármit is optimalizálnak a PAL rétegen belül az mindhárom API-ra pozitív hatással van, és nem mellesleg három helyett csak egy meghajtót írnak, vagyis az x mennyiségű humán- és pénzbeli erőforrást háromszor hatékonyabban költik el. És ennek az egésznek az a skalár egység az alapja a multiprocesszoron belül. De akkor most már járjuk végig ezt, és az a skalár egység azért jóval robusztusabb, mint egy szimpla branch egység, amit a konkurensek használnak. Ez magával hozza azt, hogy romlik az energiahatékonyság, mert egy fixfunkciós motor egy kialakított feladatra hatékonyabb, mint egy programozható rendszer. Ezt talán nem kell magyarázni, hogy miért. Ezért is van az, hogy a GCN energiahatékonysága rosszabb, mint a többi architektúra energiahatékonysága. Persze itt most kössük generációkat, tehát ne jöjjön senki azzal, hogy a GCN4 jobb, mint a Kepler/Maxwell.
  Az AMD konstrukciója annyi volt, amikor megtervezték a GCN-t, hogy kiszámíthatatlan lesz az API-k fejlődése, amiben valljuk be, hogy nagyon igazuk volt, hiszen jelenleg két új szabványos API van, és mindkettő más bekötési modellt követel. Ha megtartják a klasszikus értelemben vett branch egységet, akkor vagy az egyikben lettek volna jók, vagy a másikban, vagy leginkább egyikben sem. A programozható skalár egységgel viszont nincsenek a hardvernek direkt limitációi, úgy fog működni, ahogy azt a meghajtóban leprogramozzák. Jöhet egy harmadik vagy negyedik API is, arra is rá lehet illeszteni a GCN-t, egyszerűen csak kódolás kérdése az egész.
  Az NV és az Intel ma különböző képességű branch egységgel dolgozik. Az Intel azért érdekes (erre kitérhetünk), mert ők brute force megoldással próbálnak az API-k után menni. Egyszerűen nem léptek át a skalár egységre, hanem csúnya szóval hardveresen emuláltak egy memóriaalapú architektúrát. A Gen9 valójában nem az, de a programozó felé pontosan úgy viselkedik. Ezt úgy érték el, hogy a korábbi 255 bejegyzéses erőforrás-kezelésüket leváltották több, kétmillió bejegyzéses megoldásra. Ez ilyen furcsa öszvér megoldás. Nem tudják programozni, de a DX12 bekötési modelljét maradéktalanul kielégíti a legmagasabb szinten. Viszont zabálja a tranyót, mert nyilván azt a több szintre lebontott, szintenként kétmillió bejegyzést tárolni kell. De itt is trükköznek, mert nem tárolják az összes szintet, hanem csak mindig egyet, és a többi szintet lementik a memóriába. Ezeket a szinteket cserélgeti a hardver ezért mondható emulált memóriaalapú architektúrának (persze, ha valójában nincs annyi bejegyzés, akkor mind befér a lapkán belülre is). Ennek nyilván az az előnye, hogy amit most a DX12 megkövetel formátum és erőforrás-kezelés gyanánt, azt a Gen9 megoldja, de ha a Microsoft mondjuk úgy dönt, hogy bevezet egy új puffert vagy formátumot, akkor nem tudnak utánamenni, míg az AMD-nek egy ilyen újítás támogatása csak egy meghajtófrissítésbe kerül.
  Az NVIDIA branch egysége sokkal inkább klasszikus, tehát nem AMD-féle programozható rendszerről van szó, vagy nem Intel-féle öszvér modellről, hanem a klasszikus konstans puffer és erőforrásleíró hardver köszön benne vissza, abszolút fix limitációkkal, különállóan minden egyes pufferre és formátumra. A fenti két megoldáshoz képest ez a leghatékonyabb, ha a fogyasztásról van szó, de messze ez a legbutább, ha a működésről. Ezért van az NV-nek a DX12-vel az a problémája, hogy nem tudják támogatni a legmagasabb bekötési szintet, miközben az AMD és az Intel tudja, illetve pusztán ez a klasszikus modell vezetett oda is, hogy a Microsoftnak Root Signature ajánlásai sem jók az NV-nek. A klasszikus modell miatt a GeForce-ok alkalmaznak úgynevezett fast pathokat. Ezek a DX11-ből maradtak meg, mert ez az API sokkal limitáltabb volt az erőforrások bekötése szempontjából. Egyszerűen voltak tipikus feladatok, és arra vonatkozóan tipikusan tudni lehetett, hogy a fejlesztő milyen puffert és milyen formátumot fog használni. Ennek az oka, hogy a DX11-es modellben általában egy tipikusan jól működő megoldás volt az egyes problémákra és kész, minek kell több ugye? Az NV ezekre a tipikus megoldásokra csúnyán mondva gyorsabb feldolgozást épített be a hardverbe, így az javított a teljesítményen. Na most a DX12-ben a Microsoft ott rontotta el ezt a játékát az NV-nek, hogy lényegesen nagyobb szabadságot adott a fejlesztőknek a erőforrás-kezelés szempontjából, és ennek az alapja az, hogy a Root Signature-be csak pointereket ajánlott helyezni, amelyek leírótáblákra, root konstansokra és puffer pointerekre mutatnak. Ugyanakkor a Root Signature végeredményben elfogadja, ha direkt puffereket is rak bele a fejlesztő, de akkor ezek a pufferek különféle limitációkat kénytelenek elszenvedni, például nem támogatják az össze formátumot, illetve teljesítményvesztés is lehet a vége. Az NV azért megy szembe a Microsoft ajánlásaival, és biztatják a fejlesztőket, hogy rakjanak puffereket is a Root Signature-be, mert azzal néhány formátum erejéig elérik a hardverbe épített fast pathokat, de ha a fejlesztők a Microsoft ajánlásait követik, akkor ezek a fast pathok kihasználhatatlanok lesznek. A legtöbb DX11-DX12 váltásnál az NV hardverek sebessége ezért csökken, egyszerűen elvesztik a hardverbe épített fast pathok használatának lehetőségét. Az NV-nek a DX12-ben ez a legrémisztőbb, hogy minél inkább használják ki az API-t a programok, annál több fast pathot buknak el a hardverben. Ma még ez nem annyira kedvezőtlen (bár BF1-ben azért már erősebben látszik), de ha a programok átváltanak bindlessre, akkor minden fast path odalesz, és az ezzel nyert 20-25%-os extra teljesítmény is.

  A másik dolog a hsz-edből az API-k fejlődése. Na most az nem igazán baj, ha az API diktálja a tempót. Azért lássuk be sok területen nagyon le van maradva a rendszer az aktuális hardverdizájnoktól. Tehát mindenképpen egy nagy lépést kell tenni ebben az ügyben. Részben ezt meg is tették az érintettek. És végre figyelnek a shader nyelvre is. Mikor is volt utoljára nagy váltás? Kb. 10 éve a shader model 4.0-val. Azóta átment alattunk pár architektúra, és az újak nagyon nem úgy működnek, mint 10 éve. És persze óriásit lépünk majd előre, ami látva például a cross lane operációkat még a GCN-en belül is le fogja szakítani a GCN1/2 hardvereket a GCN3/4-től, de ez a lépés fontos a fejlődésben. Ezt le fogják követni a hardverek, mert a konzolon már ma használják a programozók az újításokat. És nem azért használják, mert mazochista mind, hanem azért, mert olyan újítások, amelyek nélkül nem igazán jó élni.

  [ 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