Keresés

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

  • válasz dezz #342 üzenetére

    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.

  • válasz dezz #336 üzenetére

    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 :D 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?

  • válasz dezz #333 üzenetére

    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 :D É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? :D 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 :D
    - É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 :W

  • válasz dezz #326 üzenetére

    Még mindig elbeszélünk egymás mellett :F

    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 :D
    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 :D

    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...

  • válasz dezz #313 üzenetére

    Akkor ez mostantól nem off? :D

    Leírom, bár nagyon egyszerű - ismét előjöttek némi alapfeltevésbeli különbségek :D

    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?

  • válasz gbors #311 üzenetére

    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
    --------------------------------------------

  • válasz dezz #304 üzenetére

    Hm. Communication breakdown :DDD

    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 :W

    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ák :DD

  • válasz dezz #301 üzenetére

    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 lenne :W

  • válasz Abu85 #296 üzenetére

    Igen, a teljesség kedvéért beletehettem volna a GF5 VS Radeon 9 párbajt - hát az elég gyászos volt.
    NV4-R4 fronton végül is nem meglepő, amit írsz, hiszen az R4 lényegében egy R3 upgrade. Nem forradalmi, viszont gazdaságos. És azért az X800XT elég jól sikerült.
    Aztán a G7 meg G6 upgrade lett (gondolom, már nagyban számoltak a G8-cal), az R5 pedig meg akarta váltani a világot. A végére sikerült is :C

    szerk. Ciklusvesztés: ez azért funny, mert az R600 tudja. És pont a G80-nak lenne nagyobb szüksége rá :F


    [Szerkesztve]

  • válasz dezz #286 üzenetére

    Khmmmm. Ezt jól benéztem. Akkor a ''sportszerűtlen'' kitételt is kéretik törölni a jegyzőkönyvből :U

    Csak az zavar, hogy sehogy nem állnak össze a G80-as teszteredmények, nem látom, milyen utasításszervezés vezethet ezekhez... Lehet, hogy a G80 nem tud thread-et cserélni ciklusvesztés nélkül?

  • válasz dezz #281 üzenetére

    Aha, értem, honnan jön a x4, csak azt nem értem, miért a float5 az alap - más issue-val a G80-nak lényegesen nagyobb az átbocsátó képessége. Kicsit fura ez a teszt btw., a float MAD serialnak a G80-on 170 körül illene lennie.
    A MUL szerintem is PR bullshit, csak nem tudom bizonyítani :DDD

    Az X1-nél meg nem csak az x1900XT és az x1650XT késett (az utóbbit már késésnek sem lehet nevezni, annyira lemaradt mindenről), hanem az x1800XT is, és ráadásul nem is lett gyorsabb, mint a 7800GTX. És kiderült persze a végén, hogy mekkora királyság az függetlenített pixel shader pool (meg az is, hogy alullőtték a textúrázókat...), de akkor már kevés volt az idő arra, hogy igazán le lehessen aratni a ''termést''. Könnyen lehet ez most a 2900XTX-szel is.

  • Hmmm, de sok víz lefolyt tegnap este óta...

    dezz, #243: Rudi és rocket leírtak már majdnem mindent innováció fronton, csak annyit tennék hozzá, hogy az nVidia magasan nyerte a mind a GF6 VS X0, mind a GF7 VS X1 meccseket anyagilag, pedig mindkét sorozatban az ATI-nak volt erősebb kártyája.
    Az extra MUL-t nézd meg a cikkben, nem vállalkoznék a visszaadására, ''Case of the missing MUL'' oldal közepén van valahol. A gond az, hogy generikus shader kódban nem lehet használni, jó ég tudja, miért.
    #252: ''A gyakorlatban ezt nehéz elérni, de ha áltagosan a felét kihozzák, akkor is 2x gyorsabb lesz a kód, mint G80-on.)'' - eztet nem értem. Mitől lenne 2x gyorsabb?

  • válasz dezz #240 üzenetére

    Köszi a teszteket, tanulságosak. Az 5-dimenziós shader teszt (#238-ban) finoman szólva sportszerűtlen, de a többiből le lehet vonni a megfelelő következtetéseket. Az enyém nem változott - 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, most az ATI annyira előreszaladt, hogy teljesítményben is sikerült a falnak menniük. 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.

    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 :O Nincs igazán jelentősége, jelenleg csak egyes speciális esetekben lehet használni - egy pixel shaderen nem segít.

  • válasz dezz #220 üzenetére

    Szerintem a 8500 nem fogja lenyomni a 7300GT-t (legalábbis az 500/700-as verziót), a 16 SP 900MHz-en eleve kevesebbnek tűnik 8 pixel shadernél @500, és akkor még ott vannak a vertex shaderek is.

  • válasz rudi #201 üzenetére

    Anandtech:

    AMD implements their R600 shader core using four SIMD arrays. These SIMD arrays are issued 5-wide (6 with a branch) VLIW instructions. These VLIW instructions operate on 16 threads (vertices, primitives or pixels) at a time. In addition to all this, AMD interleaves two different VLIW instructions from different shaders in order to maximize pipeline utilization on the SIMD units. Our understanding is that this is in order to ensure that all the data from one VLIW instruction is available to a following dependent VLIW instruction in the same shader.

    Van benne ráció, de nekem is furcsa.

  • válasz rudi #198 üzenetére

    A G80-ban az egy blokk 8+8 processzora gyakorlatilag minden erőforráson osztozik (kapcsolódó egységek, regiszterek, etc.), csak annyi a speciális, hogy két különböző szálat tudnak futtatni. Az tény, hogy ez a felépítés a float2 típusnak ideális.

    Az R600-ban a 2 szál / SIMD tömb nem párhuzamosan értendő, hanem felváltva - ha jól emlékszem, minden ciklus után cseréli őket, adatra várakozások további minimalizálása miatt.
    Amúgy ha a két float2 szál egymás mellett futna, akkor a HD2900XT az esetek többségében elverné a 8800GTX-et (ha a komplex egységet egyáltalán nem használja, akkor is átlagosan 10%-kal, legalábbis pixelben - vertex-ben meg ugye jobb).

  • válasz Abu85 #53 üzenetére

    Én esküszöm nem értem, miért van többeteknél ez a ''G80 csak szekvenciális shader kódra jó'' szemlélet. Mi akadályozza meg az nVidia shader compiler-t abban, hogy pl. egy float4 threadet szétdobjon 4 (ill. 2x2, de ez most mindegy) SIMD tömb között?

    Amúgy meg nyilvánvaló, hogy a 2900XT-ben több a potenciál, majdnem 40%-kal több a lóerő benne (mínusz amit az AA elzabál - ez mondjuk jó kérdés, mennyi). A játékok viszont nem mostanában fognak tudni ezzel élni - és ennek sok köze nincs a DX9-DX10 kérdéshez sem.

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

Hirdetés