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

• #10002 FollowTheORI nagyúr Petykemano #9979

  Új Válasz 2015-09-07 13:52:59 #10002

  Ú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

  

  FollowTheORI

  nagyúr

  válasz Petykemano #9979 üzenetére

  Én ha jól értem ebből a lényeget, ezt hámoztam ki.

  AMD: beadhatsz 1 graphics (legyen itt draw call most) + x compute szálat (64 van kezelve egyszerre full hw-ben, az előtte és közben is a gpu osztja be a feladatot -scheduler- stb). Tehát van async. Amikor ez elkezd futni (végrehajtódni) bármikor hozzáadhatsz új feladatokat azok elkezdenek azonnal végrehajtódni párhuzamosan, ha van rá szabad erőforrás. Tehát nem kell megváni sem a draw, sem a compute végét, máris megy utána azonnal az új feladat is, vagy vele párhuzamosan is. Tehát amolyan "full szabadon etethető" async.

  nVidia: beadhatsz 1 graphics (draw) + x compute szálat (32 van kezelve egyszerre hardverben, de csak részben - munkabeosztás (shedule, stb stb) az cpu/szoftver feladat). Tehát van async. Amikor ez elkezd futni (végrehajtódni), akkor viszont nem adhatsz hozzá bármikor új feladatot már, meg kell várni amíg az 1 grafikus (draw) feladat legalább végrehajtódik (+ a már eleve elindult compute is nyilván). Szóval a minimális idő a draw call futása. Utána megint hozzá lehet csapni a következő plussz feladatokat (vagy a már meglévő mögé, vagy mellé). Tehát itt a megkötés csak annyi, hogy nem kezd ez azonnal végrehajtódni az új végrehajtandó feladat párhuzamásan akármikor.

  Ez számomra nem zárja ki hogy működőképes legyen a dolog, mire kell figyelni csak?
  Hát arra hogy lehetőleg amíg a draw fut, addig ne akarj végrehajtani új párhuzamos feladatot. És lehetőleg a compute feladataid ne legyenek hosszabbak a draw call végrehajtásánál.

  Jól értem, hogy jól értem?

• #9981 gbors nagyúr Petykemano #9979

  Új Válasz 2015-09-07 08:28:26 #9981

  Ú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

  válasz Petykemano #9979 üzenetére

  Jó kis írás, érthető, és nem utolsósorban magyarázza az összes eddigi jelenséget / állítást. Ha az "üzemmódváltás" tényleg up tp 1000 ciklust igényel a Maxwellen (ez azért egy elég súlyos állítás), akkor a gyakorlatban frame-enként nem lehet több 1-2 ilyen átkapcsolásnál (sőt, ALU-limitált esetben 1-nél sem nagyon), azaz a schedulernek nagyon komolyan rendezgetnie kell a feladatokat. Ezt meg lehet csinálni egészen addig, amíg a graf és a compute feladatok nem használják össze-vissza egymás eredményeit. Ezzel meg is van a recept, hogy hogyan lehet megcsinálni a földalatti óceán AMD-s megfelelőjét

• #9980 Ren Hoek veterán Petykemano #9979

  Új Válasz 2015-09-07 06:56:14 #9980

  Ú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

  

  Ren Hoek

  veterán

  válasz Petykemano #9979 üzenetére

  Jó kis cikk (így reggel félig másnaposan )
  Ha tényleg Slow Content Switch-nek hívják már, akkor mitől async? Lehet semmit se fog gyorsulni, mert összeadódnak a ms-ek.

  Hamarosan roskadásig lesz Hardverapro 100 ezres 980 Ti-kkel

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