- Bővebb Google-támogatást kap sok Garmin óra
- Milyen okostelefont vegyek?
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- Redmi Note 10S - egy a sok közül
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Telekom mobilszolgáltatások
- A HMD visszalép az USA piacáról
- Samsung Galaxy Watch7 - kötelező kör
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Honor 200 Pro - mobilportré
Új hozzászólás Aktív témák
-
-
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? -
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 fele
-
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... -
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? -
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
-------------------------------------------- -
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ák
-
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 -
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
szerk. Ciklusvesztés: ez azért funny, mert az R600 tudja. És pont a G80-nak lenne nagyobb szüksége rá
[Szerkesztve] -
Khmmmm. Ezt jól benéztem. Akkor a ''sportszerűtlen'' kitételt is kéretik törölni a jegyzőkönyvből
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? -
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
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? -
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
Nincs igazán jelentősége, jelenleg csak egyes speciális esetekben lehet használni - egy pixel shaderen nem segít. -
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. -
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). -
É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.
Csak a fene se tudta előre, hogy az melyik. No erről ennyit.
Majd elteszem az utókornak...
Nincs igazán jelentősége, jelenleg csak egyes speciális esetekben lehet használni - egy pixel shaderen nem segít.
Új hozzászólás Aktív témák
Hirdetés
- Bővebb Google-támogatást kap sok Garmin óra
- Győr és környéke adok-veszek-beszélgetek
- Ford topik
- Filmvilág
- Milyen okostelefont vegyek?
- Vezetékes FEJhallgatók
- Milyen billentyűzetet vegyek?
- Békéscsaba és környéke adok-veszek-beszélgetek
- Xbox Series X|S
- A fociról könnyedén, egy baráti társaságban
- További aktív témák...
- Eladó Powercolor 5700XT Red Devil Dobozában
- Csere-Beszámítás! Sapphire Nitro+ RX 6700XT 12GB Videokártya!
- Csere-Beszámítás! MSI Suprim X RTX 3080 10GB Videokártya!
- BESZÁMÍTÁS! SAPPHIRE NITRO+ RX 7900 XTX 24GB GDDR6 videokártya garanciával hibátlan működéssel
- Eladó PNY GeForce RTX 4070 Ti SUPER 16GB OC XLR8
- Csere-Beszámítás! Prémium felsőkategóriás Gamer PC! X870 / R9 9950X / 9070XT / 64GB DDR5
- BESZÁMÍTÁS! 1TB Samsung 980 NVMe SSD meghajtó garanciával hibátlan működéssel
- Telefon felvásárlás!! Samsung Galaxy S21/Samsung Galaxy S21+/Samsung Galaxy S21 Ultra
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- 15,6" Dell Latitude laptopok: E6540, E5550, E5570, 5580, 5590, 5500, 5501, 5510/ SZÁMLA + GARANCIA
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest