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

• #32594 Abu85 HÁZIGAZDA Petykemano #32591

  Új Válasz 2018-01-13 12:00:40 #32594

  Ú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 Petykemano #32591 üzenetére

  Ezt ne így képzeljétek el. Megpróbálom leegyszerűsítve elmagyarázni. Most vegyünk egy tök teoretikus dizájnt, ami teszem azt 10 konkurens wave-et futtat maximum. A számok ilyen hasraütésszerüek, csak a lényeget próbálom velük átadni. Ennek a dizájnnak van mondjuk 80 blokk regisztere és 20 blokk helyi adatmegosztása. Ezen a multiprocesszoron futtatsz egy shadert, a mai igencsak pazarló dispatch alapján, aminél a statikus allokáció lefoglal 72 blokk regisztert és 18 blokk helyi adatmegosztást. Ilyen formában 8 wave futhat egymás mellett a multiprocesszoron (feltételezve, hogy egy wave 9 és 2 blokk/wave, ami egy tipikus helyzet lenne a mai programokat nézve), ami még belefér a jó hatékonyságba. De lehet komplexebb shadereket is írni, ami egyre inkább nem lehetőséggé, hanem követelménnyé válik, ahol például elég nagy probléma lesz a helyi adatmegosztás 20 blokknyi mérete. Mondjuk két-három dispatches übershader már fájhat is komolyabb anyagmodellek mellett, és előfordulhat, hogy az LDS-nél már jóval többet igényel a shader wave-enként, mint 2 blokk, akár 7 blokkot is, és ez nem extrém helyzet, hanem egyre inkább a realitás. Ilyenkor a mi kis teoretikus multiprocesszorunk alaposan bajban van, mert LDS szintjén 7 blokk/wave mellett tud 2 wave-et futtatni a 10-ből. Ezzel a hatékonysága alaposan megzuhan, mert ha az egyik wave adatra vár, akkor betölti a másikat, ami szintén adatra fog várni egy idő után, viszont nincs egy harmadik wave, amit betölthetne dolgozni, ergo az egész multiprocesszor csak áll. Ez most a probléma. A Vega lényegében úgy védekezik ellene, mintha a mi kis teoretikus multiprocesszorunknál megnöveltük volna a 20 blokknyi helyi adatmegosztást 40-re. Így már 5 wave is futhat az adott shaderrel, amivel jóval kisebb lesz a feldolgozás során az üresjárat, mert nagyságrendekkel megnő az esélye annak, hogy lesz futtatható wave, ha a többi adatra vár. Persze trükközhetnénk még olyannal, mint az utasítás-előbetöltés, de az a baj, hogy ennek a hatékonysága egy statikus allokációkra épülő hardvernél nem valami jó. Segít, de nem annyit, hogy nagymértékben lehessen rá építeni.
  A Volta is hasonló irányba lépdel azzal, hogy közös az L1 és az LDS (helyi adatmegosztás). Ez ugyan nem annyira brute force megközelítés, mint a Vegáé, de a lényeg itt is az, hogy egy nagyobb fokú konfigurálhatóság lehetőségével a futtatható wave-ek száma ideális legyen a legtöbb shadernél.
  Aztán persze a kihasználtság növelésére számos szoftveres trükk is van, ez érkezhet a program oldaláról, vagy akár a shader fordító is beállítható úgy, hogy kifejezetten a kihasználtságra fordítson, de utóbbival az szokott lenni a baj, hogy ezzel a cache-hit nem lesz túl kedvező, tehát vesztesz is vele. A legtöbb cég ezért inkább egyfajta köztes konfigurációban fordít, ahol lesz is elég wave, és a cache-hit sem lesz a padlón. Ugyanakkor a shaderek egyre bonyolultabbak, így hiába a Polaris és a Pascal dizájnja nem túl ideális a következő körre, ezért is váltott a Vega és a Volta. Ezekkel a hardverekkel kevésbé kell azon filóznia az AMD-nek és az NV-nek, hogy melyik kezét vágja le (a cache-hitet vagy a sok wave-et).
  Aztán persze a Vega és a Volta is inkább egy áthidaló megoldás. Nyernek velük úgy két-három évet, de idővel úgyis elő kell venni a hardveresen erőforrás-allokáció kérdését. A mostani, egyelőre még next-genként hirdetett fejlesztések már mindenképpen dinamikusra cserélhetik a statikus modellt. Ezzel a fenti probléma végleg megszűnik, a hardver önmagától képes dönteni az ideális futtatásról.

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