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

• #111 Abu85 HÁZIGAZDA atti_2010 #108

  Új Válasz 2014-05-07 18:42:53 #111

  Ú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 atti_2010 #108 üzenetére

  Alapvetően igaza van. Az architektúrák fejlesztését kis csapatok végzik jellemzően egy vezetővel az élen. Általában van egy fő csapat, akik az újításokon dolgoznak, és két-három segédcsapat, akik a már kész alapokat pofozgatják tovább. Nyilván senki sem mondja, hogy kis feladat egy processzort vagy egy GPU dizájnt kifejleszteni, de ezeken pár tucat ember dolgozik. Ha a humánerőforrást nézzük, akkor a szoftveres részen lényegesen több ember található.

• #106 Abu85 HÁZIGAZDA julius666 #105

  Új Válasz 2014-05-07 18:25:56 #106

  Ú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 julius666 #105 üzenetére

  Ne keverjük ide csak az AMD-t. Mindenki kivétel nélkül ugyanazt mondja, csak a megoldások között van koncepciós különbség. Az AMD a HSA-s cégekkel együtt azon dolgozik, hogy legyen egy vISA, amire elég programozni és onnan a runtime elintézi a többit. Ezzel lényegesen leegyszerűsödik a programozók számára a párhuzamosítás. Ezért vezette be a HSA a SIMT modellt, mert a programozók azt tartják a legegyszerűbbnek.

  Az NVIDIA ugyanezt mondja csak nem a HSA-ban, hanem a CUDA részeként. Az eredmény ugyanaz, csak nem lesz szabványos kód.

  Az Intel azt mondja, hogy a natív kód a legjobb. Intrinsics vagy assembly kell ide vISA-k és runtime nélkül. Akinek ez sok azoknak ott az OpenCL.

  Az alapproblémának viszont mindenki a dennard scaling végét írja le, ezért másképp kell tervezni a hardvereket.

• #99 Abu85 HÁZIGAZDA jocomen #94

  Új Válasz 2014-05-07 08:25:47 #99

  Ú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 jocomen #94 üzenetére

  Ne érezd magad kellemetlenül. Peace.

  Nagyon sokat nézem a programokat GPUView-vel, vagy GPU PerfStudióval. Ezekből látható, hogy mennyi üres ciklust futtatnak, miközben az Afterburner 99%-ra írja a kihasználást. Az is látható egyébként, hogy a kisebb GPU-kat kevésbé érinti ez a gond, mint a nagyobbakat.
  A 270X-nél a 280X jellemzően 10-15%-kal gyorsabb, miközben ~60%-kal több az ALU kapacitás és jórészt más is. A probléma az, hogy a például a Metro LL (ami a legjobb terhelést adja a PC-n) a 270X-en 75%-ra terhel, míg a 280X-en ez már csak 61%. Ugyanaz az architektúra, mégis jóval kevesebb az aktív ALU a nagyobb GPU-n. A 290X-en már csak 58%-ról beszélünk. Crysis 3-ban már a 270X-280X-290X terhelése rendre 52%-ra, 41%-ra és 39%-ra módosul.

• #87 Abu85 HÁZIGAZDA jocomen #86

  Új Válasz 2014-05-06 14:13:58 #87

  Ú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 jocomen #86 üzenetére

  A konzolok tele vannak olyan képességekkel, amelyekhez még hozzá sem nyúltak. A HSA nekik semmi, mivel aszinkron compute-ban megoldják. Olyan, mint az Infamousben a particle rendszer. Effektíve zéró sebességvesztést okoz, mert párhuzamosan fut a shadow map számításával. Az Xbox One-ban még két parancsprocesszor is van. Két grafikus feladatott is tud párhuzamosan futtatni, tehát ennek még asszinkron compute sem kell.
  Azt a hibát követed el, hogy a PC-s teljesítményből indulsz ki, ahol leolvasod, hogy az Afterburner 99%-os kihasználást ír a GPU-ra, de közben a GPUView alatt meg jó ha eléri a 30%-ot a terhelés. A számítási kapacitás 70%-ához hozzá sem nyúl a program. Ez még igaz a konzolokra is, de ezekhez idővel hozzányúlnak.

• #84 Abu85 HÁZIGAZDA jocomen #80

  Új Válasz 2014-05-06 13:32:51 #84

  Ú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 jocomen #80 üzenetére

  A mostani next-gen konzolon alkalmasak rá. Az EA Sports már ki is használja ezt a képességet az Ignite motorban (izomszimuláció, mozgásanimáció és közönség). PC-re nem tudják átmenteni, mert csak Kaveri APU-n futna. Ezért kap a PC a következő négy évben butított FIFA-t.
  Az persze igaz, hogy az EA implementációja közel sem optimális, de hát fejlesztőeszköz nélkül vágták össze a konzolok IL-jén (kvázi assembly szinten leprogramozva). Örülnek, hogy működik.

• #53 Abu85 HÁZIGAZDA kleinguru #52

  Új Válasz 2014-05-06 09:21:41 #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 kleinguru #52 üzenetére

  Soha többet. A konzolok képességeit nem lehet CPU-ba átmenteni. Ne várjátok el az AMD-től, hogy amikor már túl vannak a nehezén, vagyis ott van a technológia a fejlesztőknél az Xbox One és a PlayStation 4 személyében, akkor azt mondják, hogy mégse támogassátok, mert inkább maradunk a CPU-knál. Ez logikátlan. Nemcsak az AMD stratégiájának, hanem a fejlesztőpartnereknek is, akik csak a HSA-ért az AMD mögé álltak. A Crytek például simán pipa lesz, de annyira előrehaladottak a fejlesztések, hogy a PC fogja megszívni, mert a konzolokat kell kiszolgálni. A két konzol megjelenése mindent megváltoztatott. Most már nincs visszaút, még ha akarnák sem.

• #51 Abu85 HÁZIGAZDA stratova #47

  Új Válasz 2014-05-06 09:15:10 #51

  Ú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 stratova #47 üzenetére

  A többfoglalatos clusterek nem lesznek az AMD-nél. Ennek a helyére vették meg a Freedomot, mert azzal a lehetőségek a 4P-hez képest erősen korlátlannak tűnnek. Akár többezer processzort is össze tudsz kötni, ráadásul hatékonyan. Ilyen technológia mellett nem éri meg a hagyományos utat fenntartani.

  Nem lesz sima processzor. A CPU-IGP aránya kérdéses, de egyértelmű, hogy utóbbi nem marad ki, mert a HSA-val bármilyen nyelvet lehet támogatni. C/C++, Python, mindegyiket az összes függvényével. Persze a HSA-nak a Java szerű koncepciók fekszenek leginkább, de támogatni bármit tud. A C/C++-ra, a Javára, a .netre és a HTML5-re készül implementáció.

• #45 Abu85 HÁZIGAZDA LordX #23

  Új Válasz 2014-05-06 08:27:15 #45

  Ú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 LordX #23 üzenetére

  Nyilván sehonnan. Van egy ilyen pletyka, hogy a következő sorozat már nem használja, de eléggé kérdőjeles, hiszen a CMT előnye vitathatatlan egy olyan érában, ahol a GPGPU-s feldolgozás felerősödik. Egyszerűen felesleges magonként 512 bites (vagy akár 1024 bites) SIMD-et használni, mikor ott van a lapkában a sokkal erősebb és az adott feladatra sokkal hatékonyabb IGP. Szóval a CMT esélyes, hogy megmarad. Akár még tovább is fejlődhet olyanra, hogy nem kettő, hanem több integer cluster oszt meg egy FPU-t.
  Alternatív lehetőség persze, hogy magonként marad az egy FPU, de akkor az nem lesz 512/1024 bites. Igazából az AVX ezt nem követeli meg, ahogy látható, hogy 128 bittel is elvan a Jaguar dizájn.

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