Új hozzászólás Aktív témák
-
dezz
nagyúr
Hát elmélkedjünk.
''float MAD serial''
G80: ciklusonként 1 MAD, 2x8 pixelre/blokk, x8 blokk --> 128 MAD/ciklus
R600: ciklusonként 1 MAD / 5-way superscalar blokk (többi 4 számoló inaktív), x2 szál, x8 pixel, x4 tömb --> 64 MAD/ciklus
''float 5-instructions issue''
G80: 1. ciklus A, 2. ciklus B, 3. ciklus C, 4. ciklus D, 5. ciklus E művelet, 2x8 pixelre/blokk, x8 blokk --> 128 művelet/ciklus, de 5 ciklus kell az egészhez
R600: ciklusonként 5 különféle mat. művelet, x2 szál, x8 pixel, x4 tömb -> 320 művelet/ciklus, és 1 ciklus alatt megvan
(Itt a G80 5x több pixelt dolgoz fel, csakhogy 5x kell beolvasnia ugyanazt, az adott műveletsorhoz.)
Valami ilyesmi. -
nagyúr
Most nézem a 5-issue műveletsort, ott figyel a végén egy SQRT - tehát a sorozat nem 5 ciklus, hanem 8. Ha műveletenként a cserebere overhead elvisz +1 ciklust, akkor az összesen 13 ciklus az 5 műveletre - így már a float MAD serial és a float 5-issue eredménye ugyanarra hajaz.
De akkor meg a float4 MAD túl gyors - ilyen alapon az csak 17 lennePedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
Rigel77
tag
válasz Interceptor #50 üzenetére
Miért is ?
Egyébként kiprobáltam , és nagyon állat 8800gtx és egy 64bites vistán . Ilyen életszerü hóesést nem láttam. Ma este még neki megyek , csak koncerten voltam . Majd készitek képet és felrakom .Ps3 Ps4 id: Wiri80. Samsung S10+
-
dezz
nagyúr
''ott figyel a végén egy SQRT - tehát a sorozat nem 5 ciklus, hanem 8.''
Mármint G80-on, ugyebár...? (Szal ott 4 ciklus egy SQRT? Hol találtál erre vonatkozó adatot?)
''Ha műveletenként a cserebere overhead elvisz +1 ciklust, akkor az összesen 13 ciklus az 5 műveletre''
Leírnád egy mondatban, milyen csereberéről van szó?
''így már a float MAD serial és a float 5-issue eredménye ugyanarra hajaz.''
Már miért? Inkább úgy gondolnám, így még nagyobb a különbség: 1 cikus vs. 5 ciklus helyett 1 ciklus vs. 13(?) ciklus.
''De akkor meg a float4 MAD túl gyors - ilyen alapon az csak 17 lenne''
Na nézzük, tehát 2db float4 MAD; G80-on 8 ciklus; 345.6/8=43.2 elméleti max.
Neked hogy jött ki a 17? -
Dr. Romano
veterán
Mikor utoljára ebben a topicban jártam még értettem miről van szó, de most...
(vagy csak a buli tett be? )
[Szerkesztve]Ez....e...ee...ez egy.... ez egy FOTEL???
-
greatchaos
addikt
válasz Dr. Romano #305 üzenetére
szintén zenész...
-
rudi
nagyúr
válasz Dr. Romano #305 üzenetére
Nem árt, ha néha FPS-elnél és MHz-eknél komolyabb témáról folyik a vita. Ha nem teccik érteni vagy nem kell vele foglalkozni, vagy utána kell olvasni
Resistance Is Futile. You will be assimilated!
-
venember83
nagyúr
-
Dr. Romano
veterán
válasz venember83 #308 üzenetére
Szerintem jó ötlet lenne egy olyan topic nyitása. Egy helyen lennének a ''nehezebb'' témák és könnyebb lenne keresni is.
[Szerkesztve]Ez....e...ee...ez egy.... ez egy FOTEL???
-
nagyúr
Hm. Communication breakdown
Most akkor minden G80, lássuk...
SQRT gondolom belefér a special instruction kategóriába, az meg 4 ciklus G80-on.
Cserebere: felteszem, nem lehet büntetlenül a parallel shader-kódot ''sorosítani'', valamennyit az egyes utasítások kontextusával kell foglalkozni. Ha ez hasonlít ahhoz, ami thread-váltásnál történik, akkor ott el fog veszni 1 ciklus / utasítás. Ugyanez a feltételezés élhet a float4 esetén is.
Az összehasonlítások: csináltam egy táblázatot, mert az, hogy a sima float MAD cca. 79%-os hatékonysággal megy, felveti a kérdést, hogy vajon a többi tesztnél is bejött-e egy ilyen limitáló faktor. Így talán jobban látszik.
-----------------------------------------------------
| Ideális | 79% Teszt
-----------------------------------------------------
float MAD | 172.8 | 136.2 | 136.2
-----------------------------------------------------
5-issue (ha 5 ciklus) | 172.8 | 136.2 |
---------------------------------------------|
5-issue (ha 8 ciklus) | 108.0 | 85.1 | 56.0
---------------------------------------------|
5-issue (ha 13 ciklus) | 66.5 | 52.4 |
-----------------------------------------------------
float4 MAD (ha 2 ciklus) | 43.2 | 34.1 |
---------------------------------------------|
float4 MAD (ha 4 ciklus) | 21.6 | 17.0 | 28.3
-----------------------------------------------------
Ebből látszik, hogy ha a 5-issue 13 ciklust visz el, akkor a 79%-os eset nagyjából megegyezik a méréssel. A float4 esetben viszont egyik kalkuláció sincs a méréssel még csak köszönő viszonyban sem
Persze a fentiben sok a feltételezés, de valamitől csak fele olyan gyors a G80-on a 5-issue, mint várnám...
Többiek: Vettem az adást. Vszleg tényleg lenne értelme egy G80 VS R600 threadet indítani, ha a moderátorok tudják vállalni, hogy a fla... szóval az erős érzelmi töltetű hozzászólásokat kordában tartjákPedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
nagyúr
No akkor most a táblázat még 1x:
--------------------------------------------
_________________________|Ideal| 79% |Teszt
--------------------------------------------
float MAD _______________|172.8|136.2|136.2
--------------------------------------------
5-issue (ha 5 ciklus) ___|172.8|136.2|
-------------------------------------|
5-issue (ha 8 ciklus) ___|108.0| 85.1| 56.0
-------------------------------------|
5-issue (ha 13 ciklus) __| 66.5| 52.4|
--------------------------------------------
float4 MAD (ha 2 ciklus) | 43.2| 34.1|
-------------------------------------|
float4 MAD (ha 4 ciklus) | 21.6| 17.0| 28.3
--------------------------------------------Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
dezz
nagyúr
Válaszolnál érdemben a #304-es fennmaradó kérdéseire, a #301 figyelembevételével?
Azaz, le kellene írnod, hogy jönnek ki neked ezek a számok...
Pl. hogy lenne az 5-issue 172.8, akár 5 ciklusosan? Amikor az a szám best case float MAD serialnál tud kijönni? Elfelejtetted 5-tel osztani?
A float4 MAD-os számok meg nagyon-nagyon alacsonyak, főleg a 2 v. 4 cikushoz képest, ami mellesleg 8 ciklus kell legyen.
''Cserebere'': kizártnak tartom, hogy minden egyes float2+ operandus miatt +1 ciklusra lenne szükség. CPU thread-váltásnál le kell cserélni a regisztetek tartalmát, azt tuti megoldották, hogy itt utasításonként (float2+) ne legyen erre szükség, tovább rontva a sorosítás miatti helyzetet. Gondolom, a 2.-x. utasítás egy index hozzáadásával hajtódik végre, ami megcímzi a vector megfelelő elemét, vagy ilyesmi.
''80%'': ezen számok, és a vertex-shaderes tesztek alapján úgy tűnik, a G80, v. a driver nem utal ki 100% kapacitást semmelyik shader-típusnak, sőt, mintha le lenne fixálva egy 80/20%-os arány a PS és VS között (a GS nem tudom, hogy ékelődik be).
venember83: szerintem azért annyira nem off, mivel a cikk elsősorban nem a demóról szól, hanem a cirkuszról, ill. hogy indokolt-e, lehet-e valamilyen oka, hogy ilyen lassan fut R600-on. -
fagy53
nagyúr
Üdv!
Bocs, de látom a topic egyértelműen kétrészre szakadt és jó lenne ha valaki eldöntené,hogy a címe melyik táborra utal egyértelműen:
1, az azonos címet viselő cikk tartalmával, a Lost Planet DX9c, DX10 tesztjével foglalkozókra.
2, a G80- as struktúráját kiveséző szakmai konferenciára. -
venember83
nagyúr
Akkor miert tetted off-ba?
Ebben a topikban lehet r600 vs g80 vita (nem mintha barmi beleszolasom is lenne ), nem erdekel, csak gondoltam lenne letjogosultsaga 1 Melyviz - gpu-s topiknak, ennyi. Ott nyugodtabban lehetne vitatkozni, ervelni, ennyi.
fagy53: Attol meg, h kevesen ertik, meg van letjogosultsaga a szakmai konferencianak, foleg mig jobb topik erre nincs
[Szerkesztve] -
fagy53
nagyúr
-
AtHoS
nagyúr
Sajnos a 2. pontbeli megfogalmazás kicsit érdekes (inkább 1.b-nek kellene jelölni), mert bárki hogyan is tudna beszállni egy ilyen vitába, ha azt sem tudja, hogy magát a vitát kiváltó programot a célhardverek hogyan is dolgozzák fel. Még ha bizonyos rész feltételezésen alapul is (a nem publikált adatok hiányában) igencsak sok köze van ahhoz, hogy miért is csináltak cirkuszt a kérdéses program Demója körül.
Bár ez ugye nem felületes megbeszélése a kérdésnek, hanem kicsit mélyebbre ás és túlmutat bizonyos dolgokon.
Sajnos a mai világban már ha valami megértésére nem elegendő ''5 perc'' akkor az emberek már lépnek is tovább. A marketing pedig erre épít.read-only mode on the forum
-
fagy53
nagyúr
válasz venember83 #316 üzenetére
A szakmaisággal nekem sincs bajom, hasznosak a szakmai fórumok és mindenki maga dönti el, hogy melyikhez csatlakozik.
Nekem kizárólag a topic címével van bajom, ezt a címet olvasva nem az a szakmai téma, vita jut az eszembe ami itt van. Ha azt látnám, hogy: '' A DX10 hatása az NVIDIA GPU-k struktúrájának fejlesztésére'' sejteném a topic témáját. -
dezz
nagyúr
válasz venember83 #316 üzenetére
Hogy könnyebben megtalálhatók legyenek a bekopizott egyéni teszteredmények.
fagy53: Márpedig a cím pontosan arra utal, és a cikk is pontosan arról szól, vajon miért ilyen lassú R600-on a demó. De ez már nagyjából ki is lett beszélve; a G80 vs. R600 ''összehasonlító elemzés különféle shaderkód-esetekre'' meg abból burjánzott ki.
Amúgy javaslom neked is az ''off topic'' radiobutton használatát - ill. ha lenne olyan, akkor a ''még offabb''-at...
[Szerkesztve] -
rudi
nagyúr
válasz Dr. Romano #310 üzenetére
tudod mennyi moderátori munkát igényelne egy olyan topic tisztán tartása...?
Resistance Is Futile. You will be assimilated!
-
rudi
nagyúr
Szerintem tökmindegy mi a topic címe. Végre valahára egyszer kezd kialakulni egy értelmes társalgás komolyabb témában mint az FPS-ek meg a MHz-ek meg a flémelés. Aki érintett a társalgásban az már idetalált, szóval nem szeretnék új topicot nyitni valami mélyvizes címmel, mert akkor odatéved még egy rakás magát támában jártasnak képzelő nagyokos, aki elindítja majd a flémlavinát, amibe örömmel kapcsolódnak majd be a tényleg hozzá nem értők, és akkor pucolhatok törölhetek naphosszat (a'la tápos mélyvizes topic). Egyszer majd csinálok egy VGA-s mélyvizes topicot, de most nincs rá kapacitásom.
Resistance Is Futile. You will be assimilated!
-
R.Zoli
őstag
Sokan panaszkodtak ,hogy a Texturázó egységeke számát növelni kellene vagy gyorsítai valahogy a textirázó sebességét az R600-nak...A fudzillán volt egy hír ,hogy ilyen irányba is fog változni az R650 az R600-hoz képest...Illetve az 1 Ghz-es órajelet is el fogja érni az R650... Mindezt kb. 2,5 hónap múlva tudja... Szóval aki tud szerintem várja meg az augusztust
-
nagyúr
Akkor ez mostantól nem off?
Leírom, bár nagyon egyszerű - ismét előjöttek némi alapfeltevésbeli különbségek
Float MAD: 128 művelet / ciklus * 1.35GHz = 172.8 művelet / sec
5-issue: itt abból jön a különbség, hogy a 5-issue nekem 5 művelet - még akkor is, ha parallel végrehajthatók. Innentől, ha nincs benne special instruction, akkor a művelet / sec ugyanaz, mint float MAD esetében. Btw. a tesztben is így számoltak.
A float4 MAD viszont egy művelet, még akkor is, ha 4 SP 1 órajelnyi munkája kell hozzá. Ezért: (128 / 4) = 32 művelet / ciklus * 1.35GHz = 43.2 művelet / sec. Ha vannak a ''büntetőciklusok'', akkor a fele. Azért 2-ről és 4-ről beszélek, mert szerintem 2 ciklus alatt hajtja végre két SP az 1 float4 műveletet, nem 4 ciklus alatt 1.
Én is kételkedem egyébként a ciklusvesztésben, de jobb magyarázatot egyszerűen nem tudok elképzelni. Azt nemigen hiszem, hogy a G80 fixen kiosztaná a SP-ket ilyen / olyan feladatokra - már csak azért sem, mert a Beyond3D-sek állításuk szerint könnyen mérni tudták a maximális kapacitást.
''tovább rontva a sorosítás miatti helyzetet.''
Önmagában miért rossz a sorosítás?Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
dezz
nagyúr
''Akkor ez mostantól nem off? ''
Talán egy picit az. Bár szerintem nem sokkal jobban, mint hogy hogy fut saját gépen, mitől fagy, melyik driverrel megy, stb. Meg aztán demokrácia van, és állítólag a többséget zavarja a ''túl szakmai'' szöveg. (K10 topikban is szóvá lett téve, hogy miért vesézzük ki túl mélyen a K10 újításait. ) Halványabban talán kevésbé zavaró.
''Leírom, bár nagyon egyszerű - ismét előjöttek némi alapfeltevésbeli különbségek ''
Először is talán próbáljuk meg értelmezni a teszt számait. Nyilvánvalóan nem az összesen végrehajtott egyedi műveletek számát tartalmazza a grafikon, hanem azt elosztja az egész feladat végrehajtási idejével, mivel az a mérvadó. Így számolva nagyjából azokat a számokat kapjuk.
''Float MAD: 128 művelet / ciklus * 1.35GHz = 172.8 művelet / sec''
Na ja, ez világos. (Csak írd hozzá: serial, mert az R600-nál az alapvetően fontos tényező.)
''Innentől, ha nincs benne special instruction, akkor a művelet / sec ugyanaz, mint float MAD esetében.''
Na ja, de ha nem számolnák bele a feladatvégrehajtási időt az eredménybe, semmit sem mondana arról, hogy maga a feladat milyen hatékonységgal van végrehajtva.
(Vagy úgy is nézhetjük, hogy az 5-ös utasításcsoportot egy műveletnek vesszük - bár láttam, ez neked kevésbé tetszik.)
''Btw. a tesztben is így számoltak.''
Te ugyanazt a számot látod ott, mint a float MAD serialnál, mert én nem.
''A float4 MAD viszont egy művelet, még akkor is, ha 4 SP 1 órajelnyi munkája kell hozzá.''
A teszt egynek is veszi.
''Ezért: (128 / 4) = 32 művelet / ciklus * 1.35GHz = 43.2 művelet / sec. Ha vannak a ''büntetőciklusok'', akkor a fele. Azért 2-ről és 4-ről beszélek, mert szerintem 2 ciklus alatt hajtja végre két SP az 1 float4 műveletet, nem 4 ciklus alatt 1.''
Milyen 2 SP? A G80 egy 8-way SIMD blokkja egyféle műveletet tud egyszerre nem kettőt.
''Én is kételkedem egyébként a ciklusvesztésben, de jobb magyarázatot egyszerűen nem tudok elképzelni.''
Akkor esetleg olvasd el, amit írok.
''Azt nemigen hiszem, hogy a G80 fixen kiosztaná a SP-ket ilyen / olyan feladatokra - már csak azért sem, mert a Beyond3D-sek állításuk szerint könnyen mérni tudták a maximális kapacitást.''
Jó, akkor mivel magyarázod a vertexes tesztet, és a pixelesben kijövő 80%-os eredményt? Úgy tűnik, bizonyos esetekben bekapcsol ez a 80/20 arány. (A vertexes teszttel kapcsolatban fel is vetik, hogy a G80 abban láthatóan nem teljes kapacitásával vesz részt.)
''Önmagában miért rossz a sorosítás?''
Hát mert több ciklusra van szükség egy helyett.
[Szerkesztve] -
rudi
nagyúr
válasz venember83 #328 üzenetére
de-de, le kell őket írni, nagy kamugépek. talán 10% igazságtartalma van annak, amit írnak, és az csak utólag derül ki, melyik 10% az igaz. Persze türelmetlen valamit (mindegy mit, csak legyen valami) tudni akaróknak nagyszerű forrás, jó alap flémeléshez meg ilyenekhez. Inkább nézegesd a Beyond3D fórumát.
Resistance Is Futile. You will be assimilated!
-
nagyúr
Még mindig elbeszélünk egymás mellett
Kezdjük a kályhától:
G80: 128 stream processzor, ciklusonként 1 MAD műveletet tudnak végrehajtani, ha az adatok rendelkezésre állnak. 8 SP alkot egy SIMD tömböt, és 2 SIMD tömb egy blokkot, amiből összesen 8 van. Az egy blokkon belül a 2 SIMD tömb minden erőforráson osztozik, viszont képes eltérő tartalmú (bár azonos típusú, ie. pixel, vertex, geometry) threadet futtatni. Ez a kialakítás a jellemzően float2 művelet túlsúlyú típusú pixel shadereknek kedvez, viszont a float1 serial műveletsorok esetén sem veszítjük el a kapacitás felét. A float2+ műveletsorokon jelentősen esik a teljesítménye - ennek okát próbáljuk felderíteni
A SP-k órajele 1350MHz, ezért az elméleti maximális átbocsátóképesség 172.8 milliárd művelet másodpercenként. A special instruction (sin, cos, stb.) végrehajtás költségesebb, 4 ciklus kell egy művelethez - ezért ha az instruction mix-ben ilyen szerepel, akkor az átbocsátóképesség esik - az R600 ideális esetének számító ''4 MAD + 1 special'' sorozatra pl. elméletileg 108 milliárd művelet / sec.
R600: 320 stream processzor, ebből 256 1 MAD műveletet tud végrehajtani 1 ciklus alatt, 64 pedig vagy egy MAD műveletet, vagy 1 special instructiont. 4 MAD-only és 1 special instructionre képes SP alkot egy unitot, és 16 unit alkot egy SIMD blokkot (itt nincs egy blokkon belül két SIMD tömb, mint a G80-nál). Ez a kialakítás a jól párhuzamosítható shaderkódoknak kedvez, a serial típusú kódokon rosszul teljesít, különösen a float1 serial esetben.
A SP-k órajele 740MHz, ezért az elméleti maximális átbocsátóképesség 236.8 milliárd művelet másodpercenként. A special instruction (sin, cos, stb.) végrehajtás nem jelent extra költséget addig, amíg 1 special instructionre legalább 4 MAD esik (utána rossz esetben minden további special instruction 4 kihasználatlan MAD ciklust jelent).
A float1 serial esetben, ahol 5-ből egy SP dolgozik, az elméleti átbocsátóképesség 47.36 milliárd művelet másodpercenként.
Eddig OK? Remélem
Nézzük a teszteket:
Float MAD serial
Az R600 teljesítménye (47.2) az elméleti maximumhoz (236.8) képest 1%-on belül van.
A G80 teljesítménye (136.2) az elméleti maximum (172.8) 78.8%-a (1. probléma).
Float4 MAD parallel
Itt egy műveletet 4 SP hajt végre 1 ciklus alatt, vagy 1 SP 4 ciklus alatt, esetleg 2 SP 2 ciklus alatt (a G80-nál szerintem ez utóbbi a helyzet az egy blokkon belüli 2 SIMD tömb miatt).
Az R600 teljesítménye (58.0) az elméleti maximumhoz (59.2) képest 2%-on belül van.
A G80 teljesítménye (28.3) az elméleti maximum (43.2) 65.5%-a (2. probléma).
Float 5-instruction issue (benne egy special instruction)
Az R600 teljesítménye (224.7) az elméleti maximum (236.8) 95%-a - ez nekem még nem a probléma kategória.
A G80 teljesítménye (56.0) az elméleti maximum (108.0) 52%-a (3. probléma).
Újabb checkpoint
Kérdés, hogy a 3 probléma honnan ered. A fixált pixel-vertex felosztást én nagyon kétlem (a más magyarázatot gonosz módon inkább a teszt ATIs voltában keresném, de ez így kevéssé egzakt), de még ha feltesszük is, hogy ez a helyzet, a másik két problémára nem ad magyarázatot.
És akkor van még a sorosítás kérdése - persze, hogy egy művelet szempontjából rosszabb, ha sorosan megy, de a teljes rendszer átbocsátóképességét önmagában nem befolyásolja.
Huhhh, de hosszú lett...Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
dezz
nagyúr
Ejj. Felesleges volt ilyen szájbarágósan leírnod, amit már rég tudunk. Az első bekezdés helyett meg elég lett volna ennyi: G80-nál 2-2 SIMD blokk párosával hajt végre egy threadet. (Ezt tényleg nem tudtam, hogy 1 threaden dolgoznak együtt.)
''A float2+ műveletsorokon jelentősen esik a teljesítménye - ennek okát próbáljuk felderíteni''
Tök egyszerű, és már le is írtam (2x): A G80-nak több ciklusra van szükség a feladat elvégzéséhez (egyébként inkább float3+). Mint már te magad is leírtad, egy-egy floatX műveletet egy műveletnek számolnak. Még jó... Ha az egyedi MAD-okat, vagy más nem spec. műveleteket számolnák, mindig egyforma lenne az eredmény G80 esetén (adott floatX esetén), miközben az adott feladat elvégzési ideje más és más. Értve?
''egy SIMD blokkot (itt nincs egy blokkon belül két SIMD tömb, mint a G80-nál).''
Szándékosan használod éppen ellenkező módon a két fogalmat (tömb, blokk), mint én? Az AMD-s slide-okon a 16db 5-way s.s. SP páros egy arrayt (tömböt) alkotnak, azaz a nagy egység a tömb, és a kicsit nevezhetjük blokknak. OK?
''Eddig OK? Remélem ''
Ha nem lenne OK, akkor mégis hogy írtam volna meg a #286-os, #301-es, stb. hozzászólásokat?
Float MAD serial, 1. probléma: Ez egyelőre nyitott kérdés marad. (Hacsak nem az van mégis, amit írtam.)
Float4 MAD parallel: Maradjunk a 2x2 ciklusnál (G80). Viszont, mint már írtam, és olvashatod is a tesztben, 2db, float4-en végzett MAD tesz itt ki egy ''instruction''-t, amihez a G80-nak 2x2=4 ciklusra van szüksége. Az első tesztben kijött 136.2-ot (ami az elméleti max. 78.8%-a ugye, de most ezt tegyük félre, az 1. problémához tartozik) elosztva 4-gyel 34.05-ös számot kapunk, ami már elég közel van a tesztben kijött 28.3-hoz. [A #304-esben a flops-ból indultam ki, ami persze hibás, mert egy MAD 2 flops. De jónak tűnt, mert 1x8-as blokkal számoltam.]
Float 5-instruction issue, 3. probléma (G80 esete): Nem tudom, tudod-e, hogy a spec. funct. műveletek számára egy külön 8-way SIMD egység van, ami párhuzamosan működhet az alap SIMD egységgel. Azt viszont nem tudom, hogy a SIMD párosok 1-1 tagja egyforma utasítást hajt-e végre, vagy sem (tehát együtt egy 16-way SIMD-ként szerepelnek-e, vagy 2 független[ebb] 8-way SIMD-ként). Először számoljunk az első esettel: 4 különböző nem-spec. utasítás -> 4 ciklus, 5. spec. művelet -> 4 ciklus (párhuzamosan); egyszerre 16 pixelre, x8 cluster --> 172.8 / 4 = 43.2. (Ugye világos, miért osztok itt 4-gyel?) Teszt: 56.0. Valami még nem stimmel, de legalább közelítünk. -
dezz
nagyúr
Kicsit továbbgondoltam 1-2 dolgot.
''2db, float4-en végzett MAD tesz itt ki egy ''instruction''-t'' -> Tévedtem, 1db-bal számolva jön ki R600-nál az 59.2 milliárd művelet. (4 ciklus alatt 5db float4 MAD -> 64 (s.s. blokk) x 1.25 (utasítás) x 740MHz = 59.2 milliárd m./s.)
''Float4 MAD parallel: Maradjunk a 2x2 ciklusnál (G80).'' -> Inkább mégis maradjunk az eredeti 4x1-nél. Miért? Vélhetően a SIMD egységek 1-1 eleme adott pixelhez, stb. tartozóan végzi az adott szál adott műveletét. És egy adott pixelre természetesen nem lehet csak minden 2. utasítást elvégezni. Így tehát 4 ciklusunk lesz. 1db MAD-dal számolva így kijön ugyanaz az eredmény (34.05), csak helyesebben számolva.
[Szerkesztve] -
nagyúr
Na látom már a fényt az alagút végén, csak érdemes volt megírni a kisregényt Majd elteszem az utókornak...
Nézzük sorban:
''A float2+ műveletsorokon jelentősen esik a teljesítménye - ennek okát próbáljuk felderíteni''
Tök egyszerű, és már le is írtam (2x):
Na igen, az számomra sem volt titok hogy a 4 SP-ciklust igénybe vevő float4 MAD utasításból miért 1/4 annyit hajt végre a G80 1 másodperc alatt, mint a float1 MAD-ból Én azt feszegetem, hogy hogy a jó égbe' jön ki a 28.3, amikor az elméleti maximum 43.2, de még az első tesztnél tapasztalt rejtélyes 80%-os limit mellett is 34.05-nek kellene lenni. Még az utóbbi is 20% különbség, ami szerintem túl sok ahhoz, hogy elhanyagolhassuk - ennek tuti van valami kézzelfogható oka.
Szándékosan használod éppen ellenkező módon a két fogalmat (tömb, blokk), mint én?
Szerinted? Ezen nem fog múlni, felőlem lehet a nagy a tömb, a kicsi meg a blokk.
A special instruction sztori
Ooops. Csak hogy ne maradjak meglepetés nélkül. Még egyszer áttúrtam a Beyond3D-s architektúra ábrát, és valóban ott sunnyog 128db interpolator / special instruction egység (hívjuk SI-nek) - szerintük ugyanúgy van szervezve, mint a MAD egységek (8 tömb, mindegyikben 2 blokk, minden blokkban 8 egység).
Viszont ez több kérdést vet fel, mint amit megválaszol. A következőket szűröm le belőle:
- Ha a MAD és az SI SIMD-ek párhuzamosan tudnak működni (és miért ne tudnának), akkor az nekem azt jelenti, hogy a 172.8 milliárd op / sec mellé kapunk ''ingyen'' special instruction kapacitást, nevezetesen 128 * 1,35Ghz / 4 = 43.2 milliárd op / sec mennyiségben.
- Ez egyben azt is jelenti, hogy a teljes átbocsátó képesség szempontjából ugyanaz a best case, mint az R600-nál: 4 MAD-ra jut egy SI. Összesen 216 milliárd op / sec.
- A fentiekből elég jól látszik, hogy nem értem, hogy miért osztottál 4-gyel, ill. azt sem, hogy miért a 172.8-at osztottad
- És hogy legyen egy kis hab is a tortán: a tesztben megmérték a serial SQRT teljesítményt is, ami 21 milliárd op / sec lett - kicsit kevesebb, mint a fentebb számolt elméleti határ felePedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
szacsee
nagyúr
Szívesen bekapcsolódnék én is, de magas nekem mint tyúknak az ólajtó!
-
dezz
nagyúr
''Na látom már a fényt az alagút végén, csak érdemes volt megírni a kisregényt Majd elteszem az utókornak...''
A nagyrészt már tudott információ mely részét volt érdemes szájbarágósan újraiterálni?
''Na igen, az számomra sem volt titok hogy a 4 SP-ciklust igénybe vevő float4 MAD utasításból miért 1/4 annyit hajt végre a G80 1 másodperc alatt, mint a float1 MAD-ból''
Akkor sem volt titok, amikor pl. ezt kérdezted: ''Önmagában miért rossz a sorosítás?'' ?
A 28.3 vs. 34.05-öt én nem nevezném ''jelentős esés''-nek... (Elkülönítve a 80%-os problémát.) Szemben a 34.05 vs. 136.2-tel, aminek viszont tudjuk az okát.
''Én azt feszegetem, hogy hogy a jó égbe' jön ki a 28.3, amikor az elméleti maximum 43.2, de még az első tesztnél tapasztalt rejtélyes 80%-os limit mellett is 34.05-nek kellene lenni. Még az utóbbi is 20% különbség, ami szerintem túl sok ahhoz, hogy elhanyagolhassuk - ennek tuti van valami kézzelfogható oka.''
Nyilván. Olyan, mintha a float4 valami miatt 4 helyett 5 ciklus alatt zajlana le. 136.2/5=27.24...
''Szerinted? Ezen nem fog múlni, felőlem lehet a nagy a tömb, a kicsi meg a blokk.
Oké. De azt ugye látod, hogy nem az számít, én hogy használom, hanem hogy a cégek hogy teszik.
''A special instruction sztori
Ooops. Csak hogy ne maradjak meglepetés nélkül. Még egyszer áttúrtam a Beyond3D-s architektúra ábrát, és valóban ott sunnyog 128db interpolator / special instruction egység (hívjuk SI-nek) - szerintük ugyanúgy van szervezve, mint a MAD egységek (8 tömb, mindegyikben 2 blokk, minden blokkban 8 egység).''
Ebben most hol is van a meglepetés, azok után, hogy én is pont ezt írtam?
''Viszont ez több kérdést vet fel, mint amit megválaszol. A következőket szűröm le belőle:
- Ha a MAD és az SI SIMD-ek párhuzamosan tudnak működni (és miért ne tudnának), akkor az nekem azt jelenti, hogy a 172.8 milliárd op / sec mellé kapunk ''ingyen'' special instruction kapacitást, nevezetesen 128 * 1,35Ghz / 4 = 43.2 milliárd op / sec mennyiségben.''
Számomra is ezt jelenti. Ezzel részben magyarázható is az itt kijött magasabb eredmény a vártnál, mint már említettem.
''- Ez egyben azt is jelenti, hogy a teljes átbocsátó képesség szempontjából ugyanaz a best case, mint az R600-nál: 4 MAD-ra jut egy SI. Összesen 216 milliárd op / sec.''
Nem, mivel ez R600-on 1 ciklus, G80-on meg 4.
''- A fentiekből elég jól látszik, hogy nem értem, hogy miért osztottál 4-gyel''
Lásd eggyel feljebb.
''ill. azt sem, hogy miért a 172.8-at osztottad''
Csak próbáltam közelíteni egymáshoz a két eredményt, és gondoltam, talán itt nem játszik be az a 80%-os dolog. De oké, legyünk konzekvensek, számoljunk végig a 136.2-vel.
''- És hogy legyen egy kis hab is a tortán: a tesztben megmérték a serial SQRT teljesítményt is, ami 21 milliárd op / sec lett - kicsit kevesebb, mint a fentebb számolt elméleti határ fele''
Tényleg furcsa ez is. A 136.2-ből kiindulva ~6.5 ciklusra jön ki. -
nagyúr
A nagyrészt már tudott információ mely részét volt érdemes szájbarágósan újraiterálni?
A kisebb részt, ami nem volt tudott Csak a fene se tudta előre, hogy az melyik. No erről ennyit.
Akkor sem volt titok, amikor pl. ezt kérdezted: ''Önmagában miért rossz a sorosítás?''
Nem, ugyanis akkor is a teljes rendszer / másodperc átbocsátóképessége érdekelt, és ebből a szempontból mindegy, hogy 4 SP csinál valamit 1 ciklus alatt, vagy 1 SP 4 ciklus alatt (legalábbis ha van min. 4 SP-d). Nemde?
Nyilván. Olyan, mintha a float4 valami miatt 4 helyett 5 ciklus alatt zajlana le. 136.2/5=27.24
S ez b****a az én csőrömet. Bedugul a cső időnként, vagy mi van?
(8 tömb, mindegyikben 2 blokk, minden blokkban 8 egység).
Ebben most hol is van a meglepetés, azok után, hogy én is pont ezt írtam?
Azaz ezek a SIMD blokkok is tudnak külön thread-en dolgozni, mint a MAD blokkok.
Nem, mivel ez R600-on 1 ciklus, G80-on meg 4.
Namégegyszer, mindkettőt...
R600: az 5 utasítást 1 unit egy ciklus alatt végrehajtja, 64 unit * 740MHz * 5 utasítás = 236.8 milliárd utasítás / sec. All is well.
G80: a special instructiont 1 SI feldolgozó 4 ciklus alatt végrehajtja, ez idő alatt egy MAD SP végrehajtja a 4 MAD utasítást (lehet, hogy nem pont ez a szervezés, de ez most mindegy). Azaz 1 SI feldolgozó és 1 MAD SP együtt 4 ciklus alatt 5 műveletet hajt végre, ez átlagosan 1,25 művelet / ciklus, mindkettő feldolgozóból van 128 db, 1350MHz-en ketyegnek. Ez összesen 216 milliárd op / sec. Vagy hol a hiba?Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
elfelejtette
veterán
Hehe...
Ez nekem is magas. Inkább írok egy érdekes eredményt:
S754 Sempron 2800+ 2GHz
2x512MB DDR500 3-5-5-10 1T
Int. GF6100 alap 425MHz
1024x768
Default
Snow 2 FPS
Cave 3 FPS
Motion Blur OFF
Snow 2 FPS
Cave 5 FPS
All LOW v. OFF
Snow 4 FPS
Cave 8 FPS
Képregénynek jó volt!
Üdv."Nagyon jó dolog fontosnak lenni, de még fontosabb dolog jónak lenni."
-
dezz
nagyúr
''Csak a fene se tudta előre, hogy az melyik.''
Előre? Ha rendesen elolvasnád, amit a másik ír, pontosan láthatnád. Utána mondjuk érdemben reagálnál az egyes dolgokra, gyorsabb lehetne az egész eszmecsere.
''Nem, ugyanis akkor is a teljes rendszer / másodperc átbocsátóképessége érdekelt, és ebből a szempontból mindegy, hogy 4 SP csinál valamit 1 ciklus alatt, vagy 1 SP 4 ciklus alatt (legalábbis ha van min. 4 SP-d). Nemde?''
Nyilván (legalábbis elvileg). De attól még magához képest lassabb lesz több elemi művelet/egész művelet esetén a G80. Az R600-nak meg az 5 művelet egy időben fekszik a legjobban.
''S ez b****a az én csőrömet. Bedugul a cső időnként, vagy mi van?''
Mittudomén. Ennek kiderítéséhez kicsit több információra lenne szükség.
''Azaz ezek a SIMD blokkok is tudnak külön thread-en dolgozni, mint a MAD blokkok.''
Nem hinném, hogy más-más threaden dolgozhatnának. Már csak azért sem, mert egy közös scheduler van 1-1 8-way SIMD MAD párra + 8-way SIMD spec. funct. párra.
''G80: a special instructiont 1 SI feldolgozó 4 ciklus alatt végrehajtja, ez idő alatt egy MAD SP végrehajtja a 4 MAD utasítást (lehet, hogy nem pont ez a szervezés, de ez most mindegy). Azaz 1 SI feldolgozó és 1 MAD SP együtt 4 ciklus alatt 5 műveletet hajt végre, ez átlagosan 1,25 művelet / ciklus, mindkettő feldolgozóból van 128 db, 1350MHz-en ketyegnek. Ez összesen 216 milliárd op / sec. Vagy hol a hiba?''
Talán ott, hogy nem 4 MAD-ról volt szó, plusz egy spec. funct.-ról, hanem: 1. MUL - ezt a MAD egység csinálja; 2. MAD - ezt is; 3. MIN, 4. MAX, 5. SQRT - lehetséges, hogy G80-on mind a 3 spec. function...
[Szerkesztve] -
Dr. Romano
veterán
válasz elfelejtette #341 üzenetére
Hát ha úgy nézed az eredményeket, hogy egy X800GTO ezt a játékot nem is bírja futtatni, akkor ahhozképest egész jó ez az integrált VGA!
Ez....e...ee...ez egy.... ez egy FOTEL???
-
elfelejtette
veterán
válasz Dr. Romano #343 üzenetére
Köszi az együttérzést!
Üdv."Nagyon jó dolog fontosnak lenni, de még fontosabb dolog jónak lenni."
-
nagyúr
Előre? Ha rendesen elolvasnád, amit a másik ír, pontosan láthatnád. Utána mondjuk érdemben reagálnál az egyes dolgokra, gyorsabb lehetne az egész eszmecsere.
No. Eddig is zavart ez a stílus, de most lett elegem belőle. Az eszmecsere nálam némileg mást jelent.Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
dezz
nagyúr
-
hardzsi2
aktív tag
Na, nehogymár összevesszetek, miután ilyen jól kitárgyaltátok a témát! Igy nem illik egy szakmai vitát zárni! PEACE...
A demóról: Vista híjján (eszemben sincs szenvedni vele) a DX9-es verziót próbáltam ki. A 158.22-es driverrel 1024x768-ban (ennyit bír a monitorom) nem volt valami gyors és már az első barlang után kifagyott. Most, hogy feltettem a végleges 160.02-est [link] (amiről net-szerte csupa jókat írtak) egyből rendbejött a sebessége is és fagyás nélkül futott. [irónia] Thx nVidia, hogy 2006. novemberben kiadott hardverre sikerült fél év alatt tényleg jól használható drivert írni [/irónia]
Ami magát a játékmenetet illeti, a feelingje számomra nem valami nagy, bugyuta konzolos adaptáció; mész hentelve az apraját, mígnem jön a bossz, oszt elölről - az űrkalózok haláltánca egyenesen röhejes -, szóval biztos nem venném meg a véglegest (mégha DX10 alatt űbergrafikával is menne), de el tudom képzelni, hogy van akinek tetszik...
[Szerkesztve]flood-resistant mirror driller (cuccok: Skylake NUC és Xbox One X)
-
Komplikato
veterán
Elvileg ez már 8.38 RC7 (tehét volt elötte egy pár) és mivel ez az egyetlen forrás, nem tudni biztosan, hogy ennyit gyorsult e?
Ezért vár mindenki arra, hogy valamelyik fórumtársunk teszteljen végre!
A 8.38 RC2-ről volt az az infó, hogy 10-30%-ot gyorsult shader intenzív játékokban, konkrétan a Dark Messiah-ban hozta is a 30%-ot, viszont ugye az Source motor (eleve ATI kedvelő), más teszteket meg akkor nem találtam. Most meg csak ez van."Figyelj arra, aki keresi az igazságot és őrizkedj attól, aki hirdeti: megtalálta." - (André Gide)
-
7600GT
senior tag
Gyanusan sokat gyorsul.
Félek hogy kamu.Ha az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.