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

• #41147 Petykemano veterán stratova #41143

  Új Válasz 2019-05-29 16:44:28 #41147

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

  buildzoid Mondta nemrég egy videójában, amiben a computexet értékelte, jaja meteorpepe linkelte.
  Hogy Vega 56 Vega 64 biosszal semmivel nem teljesített rosszabbul. Tehát az is látszik, hogy gaming workload esetén az SE-kben a magas számú CUk csak pörögnek.
  Abban a spanyol lapban lehetett olvasni erről értekezést, hogy miért, de annak felét értettem csak és már alig emlékszem rá. De megkockaztatom, hogy az is igaz volt, hogy komplett CU tömbök voltak kihasználatlanok - és még a dolgozó CUkon belül is lehettek buborékok, vagyis kihasználatlan Aluk. (Hence the high async compute yield)
  Az első tudom, hogy kezelhető-e valami jobb ütemezéssel, utóbbi esetre tud megoldás lenni ha egy 4×16-os tömb külön kezelhető.

  Talán az kimondható, hogy a géming workload granularitása finomabb, mint egy hpc workload, vagyis az különböző műveletekhez egy órajelciklus alatt csokorba forgató adatok mennyisége kisebb, mint hpc esetén.

  Na, de igazából azt akartam mondani, hogy ha eddigi ismereteink alapján elvileg valahol 9-11 CU/SE lehet az ideális, de legyen 12... (egyébként ez nem lehet amiatt, hogy ugye volt róla szó, hogy az L1D$-en 4CU osztozik - lehet-e Hogy ez maximum? Tehát a Vega 64 esetén 4CU, de mondjuk a polaris esetén 2-3 csak?)

  Na szóval 12cu az ideális. Akkor ha ezt 8 SE-re osztjuk, akkor csak 6CU. De ez 6 olyan CU, ami akár 2x annyi műveletet is el tud végezni. Tehát ha a GCN esetén a 12 valamiféle ütemezési-skálázódási limit volt, akkor az RDNA esetén is mondjuk 8CU/SE esetén talán el is jutottunk

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

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