Aktív témák

• #3060 gbors nagyúr ftc #3050

  2007-08-11 22:50:46 #3060

  Ö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 ftc #3050 üzenetére

  ftc, #3050
  Miért kell R/W cache?
  
  VaniliásRönk, #3048
  Megpróbálom röviden - erősen teória, de attól még lehet köze a valósághoz
  Szóval, az közismert, hogy a G80-ban van egy kis architektúrális optimalizáció a float2 PS-hez - egy tömb 16 SP-je 2x8-ként 8 pixelt dolgoz fel egy órajel-ciklus alatt. Viszont sehol nem találtam arra utalást, hogy a jellemzően float4 vertex-eket hogyan dolgozza fel. Nemrégiben hallottam egy olyat (by Abu85), hogy a G80-ban a 128 SP mellett nem 128, hanem csak 32 SF ALU van, azaz 4 SP-re jut egy SF (azaz ugyanaz a felállás, mint az R600-ban - nocsak!). Bár nem vagyok shader-programozó, az ATI vect5D megoldásából arra következtetek, hogy a VS kódokban jellegzetes lehet egy SF művelet (minden bizonnyal főleg trigonometria) a float4 feldolgozáshoz kapcsolódóan. Első feltevés: a G80 ciklusonként 32 vertex kódsort kezd el feldolgozni, minden SIMD tömb 4-et, és ilyenkor 4-way SIMD-ként működnek. Ezt alátámasztani látszik, hogy a VS tesztekben a G80 azonos darabszámot csinál float1 és float4 MADD-okból / sec, holott az utóbbi ugye 4x-es kapacitást igényel. Ez azt jelenti, hogy egy float1 VS kód helyből az elvártnál 4x lassabban fut.
  Miután az SF művelet 4 ciklusig tart, ezért a következő 3 ciklusban csak a 32 SF dolgozna, a 128 SP csak vakarózna. Második feltevés: erre a 3 ciklusra PS kódot tesz be a scheduler, és akkor megy tovább a VS kód következő műveletére, amikor végzett az SF. Ez ugye azt jelenti, hogy pure VS kód esetén ismét el lehet osztani néggyel a teljesítményt.
  Már csak az a kérdés, hogy közkézen forgó VS tesztekben, ahol egy darab szerencsétlen MADD-ot szeretnének minél több példányban áttolni a shader core-on, miért ilyen gyenge a G80. Harmadik feltevés: a fenti 1 VS + 3 PS ütemezés be van drótozva a schedulerbe, nem pedig az adott vertex kód függvényében kerül bevetésre. Ez elsőre überparaszt dolognak tűnik, viszont sokkal egyszerűbb megcsinálni (és letesztelni...), mint az ATI varázsgömbbel vetekedő schedulerjét -> kevesebb tranzisztor és korábbi piacra dobás. És ami a legjobb benne, hogy ha áll az a feltételezés, hogy PS:VS > 3:1 (márpedig ez egy játéknál szinte mindig áll), akkor akkor sem jelent veszteséget, ha a float4 vertex művelethez nem kapcsolódik trigonometria.
  
  GS-nél nem tudom mi a szitu, de valami igen hasonlót tudok elképzelni, esetleg más számokkal. Ill. itt fontos a feltételezésként használt PS:GS arány, mert a gyakorlati tapasztalat hiánya miatt ezzel éppen lehet nagy bakot lőni.
  
  
  [Szerkesztve]

Aktív témák