Új hozzászólás Aktív témák
-
dezz
nagyúr
-
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] -
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. -
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
''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] -
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. -
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
-------------------------------------------- -
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? -
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. -
Abu85
HÁZIGAZDA
Én ezt másképp látom, az NV3x vs R3xx-at egyértelműen megnyerte az ATi. De az NV4x vs R4xx, szvsz az NV4x nyerte. Nem a teljesítményt nézem, hanem az egész rendszer összképét. Az NV40 sokkal fejlettebb volt az R4xx-nél. A G7x vs R5xx szívem szerint döntetlenre hoznám. Bár ha választani kell akkor G7x, mert az tudta a VTF-et.
-
dezz
nagyúr
''Az 5-dimenziós shader teszt (#238-ban) finoman szólva sportszerűtlen''
Nem ''sportszerűtlennek'' nevezném, egyszerűen csak a worst case az egyik oldalon, mint ahogy a full dependens ''float MAD serial'' meg a másikon. Már csak az a kérdés, egy áltagos kódban mennyi a végrehajtást erősen negatívan befolyásoló dependencia-sűrítmény, illetve az ilyen kevert utasítástípusok egymás után, kevéssé dependensen. (Persze attól is függ, ki hogy írja... Úgy tűnik, adottak a feltételek ahhoz, hogy egyes programok a G80-on fussanak jobban, mások meg az R600-on.)
''hiába innovatívabb az ATI, nem igazán tudják, hol a határ - az nVidia jobb pozícionálása (mind piaci, mind műszaki!) korábban csak pénzügyi előnyt hozott''
Ezzel pontosan mire célzol?
''most az ATI annyira előreszaladt, hogy teljesítményben is sikerült a falnak menniük.''
Hát ezzel? Órajelben v. hőtermelésben el tudok képzelni falnak menést, de teljesítményben hogyan?
''Gondolom, az AMD-nél most külön részleg alakult arra, hogy a shaderprogramozókhoz imádkozzanak - ha elkezdenek az engine-ekben megjelenni a jól parallelizálható pixel shaderek, akkor van remény arra, hogy az év második felében (vagy inkább 4. negyedében) kijöjjön az R600 brutális lóereje.''
Az R600-nak jobban fekvő kevert kód alkalmazásának ösztönzésére gondolsz?
''Ja és a G80 extra MUL-ja. A Beyond3D-sek megtalálták, de olyan komplikált, hogy első olvasásra egy az egyben átsiklottam felette''
Hmm, akkor én is ''átsiklottam felette'' (túlzottan nem is kerestem ), de akkor hol is van?
''Nincs igazán jelentősége, jelenleg csak egyes speciális esetekben lehet használni - egy pixel shaderen nem segít.''
Hát, végülis előfordulhat, hogy egy MAD után (ami eleve tartalmaz egy MUL-t) jön még egy MUL, ugyanazzal/-okkal az operandussal/-okkal. Vagy összetettebb eset kell hozzá?
Abu85: hát, néha csak ilyenkor van időm nyugodtan olvasgatni.
[Szerkesztve] -
dezz
nagyúr
No, akkor tehát azt a 16 threadet szabadítanak rá egy SIMD tömbre. De akkor egészen véletlenül az a 16 thread nem ikertestvérek? Ezt indikálná a SIMD tömb elnevezés. (Tehát ugyanazok a műveletek, csak különböző elemeire egy pixel v. egyéb halmaznak.)
Akkor viszont mitől lesz ez VLIW? Egy utasítás, és sok operandus? A G80 is 8 pixelre, stb. hajtja végre ugyanazt az utasítást egy blokkjában, de ott nincs VLIW-zés, egyszerűen a következő 8 elemet veszi, vagy ilyesmi. Akkor ide minek?
#229: na igen, valamivel gyengébb ''MAD teljesítményben'' (8*4*500=16000 vs. 16*900=14400). Viszont, utóbbinál a kihasználtság mindig 100%, és ha hasonló a nagytestvérhez, a 16 MAD egység mellett van ott x egyéb (spec. funct.+stb.) egység is. (Meg rebesgetnek még valami plusz MUL-t is, csak még senki sem találta meg.) Bár még azzal is talán max. egálban vannak. Mindegy, a 7300 még nem a legrosszabb DX9 gamer kártya. A 8500-assal viszont szerintem eleve nem sokan akarnak majd DX10-ben játszani.
[Szerkesztve] -
rudi
nagyúr
Gondlom, nem véletlenül gyúr az NV float2-re, hiszen jelenleg ez a meghatározó utasításformátum a pixel shadereknél, és szerinem az árnyalási képletek jellege miatt ez is marad. Persze VS és GS-nélmár a float4 a gyakoribb, csak nagy kérdés, hogy egy modern kódban ezek a shaderek milyen arányban lesznek.
Ezt a ciklusos dolgot hogy érted az R600 kapcsán? Nekem elég bizarrnak tűnik.
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.)
''
) Halványabban talán kevésbé zavaró. 
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X3D 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- 4 év gari - magyar bill. - Lenovo ThinkPad Z13 G1 - AMD Ryzen R7 Pro 6850U, 13.3" 2.8K OGS érintő
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
- PlayStation Network Card (PSN) ajándékkártyák, egyenesen a Sony-tól!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest