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

• #196 Abu85 HÁZIGAZDA Meteorhead #195

  Új Válasz 2014-02-09 23:14:00 #196

  Ú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 Meteorhead #195 üzenetére

  Nekünk olyan platform kell, amivel egyszerre lehet megoldani azt, hogy az egyszer megírt kód teljesítménye minden architektúrán skálázódjon.
  Ha az AMD írna egy sima C++ fordítót GCN-re nem sokat érne, mert azzal a fejlesztő célozhatná ezt az architektúrát és kész. Minden megvan a hardverben ehhez, hiszen vannak virtuális funkciókat, kivételkezelés, rekurzió, pointerek, de az architektúra generációról-generációra változik, így folyamatosan új fordító kellene. Teljes architektúraváltásnál meg nulláról kellene ezt újra felépíteni. Márpedig úgyis lesz idővel új architektúra, hiszen épeszű cég nem fogja a skálázhatóságot orbitális méretű gyorsítótárakra bízni, ami elveszi a GPU hatékonyságát.

  Olyan rendszer kell, amivel a ma írt kód 15 év múlva is futni fog.

• #194 Abu85 HÁZIGAZDA Meteorhead #193

  Új Válasz 2014-02-09 18:54:57 #194

  Ú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 Meteorhead #193 üzenetére

  Technikailag a Keplerben és a GCN-ben is megvan minden, hogy bebootoljanak egy OS-t. Még a Fermi is jó lehet itt, de akár az ARM Mali-T600/700 is.

  Ha strukturálisan nézed a GCN CU és a Silvermont Larrabee verzióját, akkor túl sok eltéréssel nem találkozol.
  GCN:

  decode == programozható skalár egység == 4 x 512 bites SIMD - 4 x 64 kB regiszterterülettel (+64 kB LDS) == cache rendszer

  Larrabee (Silvermont) mag:

  decode == programozható egység == 512 bites SIMD - 8 kB regiszterterülettel (hagyományos értelemben nincs LDS) == cache rendszer

  Az értékek mások, de a felületes struktúra azonos. Az OpenCL-ért elsősorban azért sírnak, mert ezt a rendszert ebben a nyelvben a legegyszerűbb hatékonyan programozni.

• #190 Abu85 HÁZIGAZDA Meteorhead #189

  Új Válasz 2014-02-09 17:41:14 #190

  Ú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 Meteorhead #189 üzenetére

  Egyelőre csak az AMD-nek érdeke megszavazni egy teljesen compute irányra épített API-t a GAB-ban. A többieknek ez nem ideális.
  A compute nincs ingyen. Szükség van nagyon sok regiszterre, hatékony flow control, nagyon gyors elérésű elsőszintű cache-ekre és lehetőleg OOO logikájú compute parancsprocesszorokra. Ezek mindegyike beépíthető, de mindegyik ilyen extra fogyasztani fog. Nem is keveset.
  Jelenleg az AMD kivételével mindenki az ultramobil piacot célozza a grafikus architektúrájával, tehát a fenti területeken kompromisszumot fognak kötni, hogy ne fogyasszanak túl sokat. Éppen ezért a compute csak korlátozott mértékben jó a többség számára. Ezt az MS-nek is figyelembe kell venni.

• #100 gbors nagyúr Meteorhead #81

  Új Válasz 2014-02-07 13:32:00 #100

  Ú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

  

  gbors

  nagyúr

  LOGOUT blog

  válasz Meteorhead #81 üzenetére

  én kérek elnézést - nem kussol, mert mozog a szája, de mondani nem mond semmit

• #82 atti_2010 nagyúr Meteorhead #81

  Új Válasz 2014-02-07 13:01:53 #82

  Ú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

  

  atti_2010

  nagyúr

  válasz Meteorhead #81 üzenetére

  hogy a drivereit újraszervezi,

  Eddig mi a tökömet csinált????

• #71 vinibali őstag Meteorhead #20

  Új Válasz 2014-02-07 12:36:40 #71

  Ú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

  

  vinibali

  őstag

  válasz Meteorhead #20 üzenetére

  az OpenGL-hez hasonlóra gondoltam

• #70 partxxx tag Meteorhead #38

  Új Válasz 2014-02-07 12:36:07 #70

  Ú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

  

  partxxx

  tag

  válasz Meteorhead #38 üzenetére

  úgy értem hogy felette áll, hogy kell dx a működéshez, viszont bizonyos funkciókat megkerül és optimálisabban hajtja végre, jól gondolom ?

  tehát egy optimalizált dx felett futó, addigra 1-2 éves mantle nem feltétlen fog elsorvadni, mert további optimalizálást nyújthat

  ha rosszul fogom fel a működést akkor javítsatok ki

• #27 Abu85 HÁZIGAZDA Meteorhead #20

  Új Válasz 2014-02-07 11:00:58 #27

  Ú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 Meteorhead #20 üzenetére

  A Unified Memory nem gond. Egy közös IL kell és kész. A HSA sem más és az is támogat ARMv8, MIPS64 és AMD64 architektúrákat egyszerre. Szóval az NV ARM-os integrációja ilyen koncepcióval simán használható. A queue nyelv a gond. Ott nincs egyetértés a gyártók között. Legalábbis a HSA-n kívül semmiképp.

  (#25) wednesday: Természetesen az új API hardveres funkciókat is követel. De ha az Xbox One API-ja az alap, akkor nem feltétlenül szükséges hozzá új hardver. Attól függ, hogy a base funkciók mennyire komplexek. Ha jól rakják össze, akkor a GCN és a Kepler megfelelhet. Ha többet akarnak, akkor csak a GCN lesz jó. Ha még több kell, akkor pedig mindenkitől új hardverekre lesz szükség. Ha van egy kis eszük, akkor a base funkciókkal a GCN/Keplert célozzák. A többi pedig jó lesz kiterjesztéssel.

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