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

• #206 Abu85 HÁZIGAZDA VinoRosso #204

  Új Válasz 2009-04-24 07:59:38 #206

  Ú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 VinoRosso #204 üzenetére

  Miért lenne feltétlenül bonyolult az amiben sok függőség van? Ha az egyszerű utasítások függnek folyamatosan egymástól, akkor már rossz a helyzet az R600 esetében. Ezért ilyen gyenge a chip Folding teljesítménye. Erre mondta a Folding egyik programozója, hogy ezen nem lehet javítani, mert az R600-at az AMD a DX10-re tervezte, azaz a legjobb chipet akarta a grafikai számításokra. Ha a rendszer csak olyan utasításokat kap amik függnek egymástól, akkor a shader processzorok 80%-a pihen, mert egyszerűen nem tud a lehetséges 1+1+1+1+1 co-issue módban működni.
  A G80-nál olyan, hogy függőség nincs, mert ez az architektúra stream rendszer. Komponens folyamokon dolgozik, azaz az utasításokat az egymás után következő komponenseken végzi el. Gyakorlatilag a G80 mindig 100%-os kihasználtságot garantál. Ami nagyszerű a programkódnak. A probléma az, hogy a belső cache rendszer irgalmatlanul gyengén bánik az ideiglenes adatokkal. A stream processzorok regisztereinek mérete is kevés. Az ütemező elemzi a feladatokat, és ha túl bonyolult a párhuzamos végrehajtásra, akkor a 8 utas Streaming shader processzorból annyi utat lekapcsol, ahány szükséges a működéshez. Ez persze azt is magával vonhatja, hogy egy ilyen blokkban a 8 stream egységből csak egy fog működni, és az felhasználja a többi egység regiszterét. Előfordulhat persze az is, hogy még így is kevés lesz a regiszterterület, így a hely hiányában az adatok a TPC cache-be lesznek kiírva. Gondolom nem kell ecsetelni, hogy ez mekkora probléma a sebességre nézve. A rendszer aktív processzorai ilyenkor kvázi 10-15 órajelenként dolgoznak (most nem tom pontosan mekkora a TPC cache késleltetése). A G200-nál például a stream processzorok regiszterméretét megduplázták és a belső gyorstárak összmérete is a hatszorosára nőt. Ez nagyon látszik a DX10-es példaprogramokban. Főleg a Geometry Shadert, vagy Cube Map tömböt használó alkalmazások esetén ... utóbbi esetében szó szerint megfekszenek a GeForce-ok, még a GT200 is az R600 alatt van, túl bonyolult nekik a feladat. Persze a GT200 még így is tízszer gyorsabba a G80-nál, csak az R600-hoz még ez is kevés.

  Az NV-nek ezért lenne fontos legyűrni a DX-et, mert a CUDA-ban jó eséllyel nem használnak majd, olyan baromságokat, mint Geometry Shader és Cube Map tömb. Amikkel egyébként Globális Illuminációt és dinamikus környezeti tükröződést lehet csinálni, ergo egy újabb grafikai ugrás lenne. A DX10.1-ben már az MS azt is megoldotta, hogy a Cube Map tömbök számítása párhuzamosan történjen. Hmm ... vajon miért is nem támogatják a GeForce-ok a DX10.1-et, ha annyira a grafikára pályáznak? Vagy lehet, hogy mégsem a modern eljárásokra épülő grafikai számításokért rajonganak?

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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