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

• #53 Abu85 HÁZIGAZDA Fiery #37

  Új Válasz 2013-07-28 12:46:22 #53

  Ú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 Fiery #37 üzenetére

  Az OpenCL-nek az a gondja, hogy a kód teljesítménye és működése nem portolható direkten. A későbbi fejlesztésekkel az lesz, de ma még nem az. A gondot tetézi, hogy az AMD OpenCL implementációja igen specifikus, tehát a manapság jellemzően erre optimalizált programok igen rosszul működnek a többi cég OpenCL meghajtóján. A WinZipnek ez volt a baja egy évig, így a 16.5-ös verzió nem is működött az Intel és az NV termékeken, de a 17-es verzió már igen. Az Adobe jelenleg ugyanezzel a gondal küzd. Működik a többi hardveren az OpenCL implementációjuk, de annyira az AMD-re szabták, hogy iszonyatos hátrányban vannak a többiek a sebesség szempontjából. Ezért vannak a HSA mellett, mert azzal portolható teljesítményű kódokat írhatnak.

  John Carmack sosem volt a direkt programozás mellett. Sweeney volt az, aki azt mondta régen, hogy a direkt GPU programozás a jövő, és lesz egy GPU-architektúra, ami domináns lesz, és csak arra kell dolgozni. A többiek majd szépen kiesnek. Ezzel ugye az a probléma, hogy nyilván a konzolok miatt ezt az AMD igen támogatja, hiszen a GCN lett a Sweeney által vizionált domináns architektúra, de szerinted egy Intel vagy egy NVIDIA ehhez mit szól? Az meg kizárt, hogy háromszoros munkát végezzen egy fejlesztőcsapat, mert egyszerűen nincs meg rá az anyagi keret. A PC-s porton nincs pénz, a konzolos portok hozzák az eladást.

  Carmack a HSA-s jövőképről ennyit mondott egyszer egy interjúban: "The current generation Fusion parts are really a separate CPU and separate GPU connected on the die by better or worse interconnects, but their vision is integrating them much more tightly such that they share cache hierarchies, address space, and page tables. I think its almost a foregone conclusion that its going to be the dominant architecture in the marketplace ..."
  Igazából őt ma a megatextúrázás érdekli, és jelenleg két cég (AMD és NV - még az ARM is, de ők ultramobil szint) kínál olyan GPU-architektúrát, ami tartalmaz MMU-t, és képes bindless textúrázásra. Ezzel már hardveresen támogatható a megatextúrázás, ahogy az OpenGL ezt fel is vette ARB-be. Az AMD annyiban kínál extrát a PRT-vel, hogy a GCN úgy támogatja a megatextúrázást, hogy minden hardver által támogatott textúraformátum megfelelő, így nem kötelező tömörítetlen textúrát használni.

  A GPU-k tervezése nem olyan egyszerű, mint azt sokan gondolják. Sokkal nehezebb összerakni egy ilyen rendszert, mint egy CPU-t. Bárki le tud rakni az asztalra egy működő GPU multiprocesszort, mert az nem nagy dolog, de egy olyat, ami skálázódik is, az már nehéz. Oda 10-20 év tapasztalat kell és nem dollármilliárdok. Tipikus példa erre a Larrabee. Az Intelnek is volt tapasztalata és szakembergárdája, csak a vezetőség elküldte azokat az embereket, akik azt mondták, hogy a Larrabee sohasem fog működni. Itt követték el a hibát, hallgatni kellett volna rájuk. Főleg John Gustafsonra, Michael Abrashra, vagy Andrew Richardsra. Ők a világ legokosabb emberei a parallel computing területén, és semmibe vették a véleményüket. Végül nekik lett igazuk.
  A Larrabee ma a MIC. Annak hatékony kihasználásához van a vector intrinsics, de ez olyan mintha assemblyben programoznál. Nem fogom elhinni a programozókról, hogy ez számukra kedvezőbb, mint a C++. Szóval én ezt a direkt programozást kapásból kilövöm, senki sem szeretne Assembly szint közelében data parrallel kódot írni, még az Intel kedvéért sem.

  [ 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