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

• #10243 sayinpety tag gbors #9674

  Új Válasz 2015-09-11 13:32:23 #10243

  Ú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

  

  sayinpety

  tag

  válasz gbors #9674 üzenetére

  Volt szivas, am megoldottuk. Sajnos developer driverek sokat valtoznak, nem stabilak meg. Jelenleg multi-engine & sync code eredmenye +4% Geforce es +22% Radeon. Am mi software tessellationt futtatunk async compute modeban. Specialis eset.

  Szerintem Nv tul ideges. Latszik rajtuk, am nem ertem miert. Tobb alternate pathot irtunk be enginebe fel ev alatt. Sokat segitett a Geforceoknak. Mar hasonlo teljesitmenyu a 980 es 290x. VR-tol felnek. Mi VR tamogatasunk nem lesz kesz jovore. Elmondtam nekik. Latszott rajtuk a megkonnyebbules. Vicces volt. :-)

  Szerintem Nv tul optimista volt. Tobb programozojuk belatta nem jo a Gameworks. Hiaba hoztak 4 effektet, egyiket se tudom beepiteni. Legalabb egy evvel csuszna engine. A kiado nem orulne. Par uj Gameworks effekt hasznal conservative rasterizationt es ROVsot, am olyan enginerol nem tudok, ami tamogatna. En jovore kezdem tervezni az updatet. Akkor veszem szamitasba uj lehetosegeket. Ha minden jol alakul conservative rasterization es ROVs algoritmusokat harom ev mulva tudunk beepiteni. Nem varazsutessel fejlesztunk! D3D12 tul nagy update. Nem lehet mindent gyorsan tamogatni. A tamogatast eloszor alapfunkciokra korlatozom, plus multiadapter. Ha mukodik lepunk tovabb. Meg be kell epiteni a Vulcan APIt. Mantle miatt nem varok nehezseget, am par hetet elvisz.

• #9688 FollowTheORI nagyúr gbors #9674

  Új Válasz 2015-09-01 16:31:17 #9688

  Ú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 gbors #9674 üzenetére

  31+1 -et én most itt queue limitnek néztem, nem compute motornak... szóval a moderált is ki tudja mennyi... persze lehet jóval kevesebb meg több is.
  De tekintve hogy mennyi mindent szélsőségesen paralellizáltak ebben a motorban (amivel amugy semmi gond, hisz ez a cél), könnyen lehet túlvannak a 32 queue-n (összegészében)...

  És igazából a problémát is abban gondoltam hogy mi van ha ennél többet akarnak rátenni egyszerre és a driver ezt úgy kezeli le hogy felbontja 31/2-es "csomagokra".
  És ha nagyon beesik a teljesítmény az azért van, mert pl van egy 32-es csomag (1 graf + 31 compute queue) a második, meg a harmadik meg csak compute (nincs graf), neadjisten egy egy ilyen 32 csomag után még pre-emp is kell ami szintén időkiesés. Aztán kezdődik elölről.

  Mondjuk AMD-n meg jól megy, elég lehet akár azis ha csak 32-nél több, de 64nél kevesebb, és pl emiatt nem kell (meg amugyse náluk pre-emp), plusz az egészet egyszerre le is tudják kezelni, nem kell pl ketté bontani. Ami ugyan lehet tovább tart mint nVidián egy 32-es "csomag", de a többi "overhead" miatt mégis az AMD jobb összidőben. Ki tudja lehet akár 100%-al is, ami már nevezhető durva beesésnek.

  Na mindegy tényleg keveset tudunk, arról is a bench mit akar csinálni és a hw/driver is, hogy működik.

  Meg mást nem tudok elképzelni, mert ha a nVidia már rég közölte és dokumentálta hogy a Maxwell 2 tud egyszerre compute és grafikát is, a Maxwell 1 és előtt meg csak egyik vagy másik, akkor önmagában ez nem lehet baj. Tehát mennie kell egyszerre. Inkább csak valami limitáció van máshol rá hogy mennyi az annyi, vagy hogyan kell etetni.

  Szerk +, mondjuk ez a BY3D-s otthoni barkács tesztprogi is lehet ezt jelenti, mert minden egyes 32-es csomagnál nőtt az idő... AMD meg egyforma ugye.
  Ez kicsit olyan mintha 32-es csomagokra kéne bontania a drivernek a queue-kat.
  Aztán persze ugyis tévedhetek, hisz nem értek hozzá ennyire (sem).

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