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

• #24170 Petykemano veterán HSM #24167

  Új Válasz 2016-11-19 00:19:32 #24170

  Ú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

  

  Petykemano

  veterán

  válasz HSM #24167 üzenetére

  Nem ástam el magam az apik történetében, csak feltételezem, hogy magától (csak szoftveres irányból) nem nagyon születik semmi. Feltételezem, hogy az apiban egy feature akkor és úgy jelenik meg, ha legalább egy hardvergyártó támogatja, akarja és kellően képes befolyásolni az api fejlődését ahhoz, hogy tényleg bele is kerüljön.

  Ha tehát abból indulunk ki, hogy ha a hardvergyártók nem akarják, úgy nem újhodik meg az api, akkor a meg nem újhodó apihoz racionális igazítani az architektúrát.

  A status quo akkor borul, ha egy hardvergyártó új képességet tesz a hardverébe, amit idővel az api támogatni kezd, mert attól jobb lesz. (Legalább annak az egy hardvergyártónak)

  Azt mint látod, sokan vitatják, hogy jobb lett-e így, mintha minden hardvergyártó méginkább a meglevő API-hoz igazította volna az architektúráját (most tekintsünk el attól, hogy az AMD-nek más tervei és lehetőségei voltak)

  (#24168) TTomax
  Nincs kint, és biztos nem örülnek ennek ők se. Feltétlezem, hogy erőforrás hiányában.
  Úgy tűnik, hogy a konzol biznissz nem anniyira mint kiemelkedő bevételi forrás számított az AMD életében, hanem mint hullám, aminek farvizén evezhetnek. A közvetlen pénzügyi hatáson túl teljesen nyilvánvalóan látszik, hogy a hardverfejlesztéseiket hozzáigazították a konzolokhoz. Akkor lett Polaris, amikor jött a PS4Pro. És olyan is. És akkor lesz Vega, amikor jön a XB Scorpio. Ezt biztosan nem kiszúrásból csinálják, hanem költséget igyekeznek minimalizálni. Nem biztos, hogy jó stratégia, mert minimális költség lehet ugyan, de közben elúsznak a lehetőségek. Lehet, hogy a P10 nem került szinte semmibe, egy külön nagyobb lapka tervezése meg soktízmillióba lett volna, de így biztosan bukták a felsőházat ebben az évben. lehet, hogy a vega nem került szinte semmibe, de ki tudja jövőre mivel kell versenyeznie? Mert lehet, hogy nem az 10X0 szériával.
  Ugyanakkor - még mindig az AMD szemszögéből vizsgálva az eseményeket - az is igaz, hogy az idő nekik dolgozik: csak meg kell várniuk, amíg beérik a szoftveres oldal (Dx12, Async C, Shader intrinsics, meg az új mantra a Shader Model 6). és közben nulla hardveres befektetéssel képesek versenyképesek (20%) maradni. Jobb lenne, ha küszködnének ilyen Furyszerű szörnyekkel, amiket aztán ezért-azért-amazért mégse venne senki? Lehet, hogy kiszámolták, hogy nem. Mindeközben fel-felbukkannak olyan címek, ahol a Fury X kitesz magáért.

  Abban igazad lehet, hogy DX12 olcsóbbá tette a portolást. Azt nem tudom megítélni, hogy ha nem lenne DX12, akkor mi lenne. Drágábbak lennének a portolt játékok? Vagy később készülnének el? Vagy el sem készülnének? Vagy csak kevesebb pénz maradna a kiadónál?

  Annyi előnye mindenesetre van talán, hogy az egyszálas teljesítményben gyengébb többmagos processzorokon jobb lett.

  (#24169) #Morcosmedve
  Én nem mondtam, hogy az AMD húsz lenne.
  Az, hogy nincs 100k feletti AMD alternatíva mit bizonyít, vagy mire utal?

  Találgatunk, aztán majd úgyis kiderül..

• #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