- Samsung Galaxy Z Fold5 - toldozás-foldozás
- iPhone topik
- Prohardver app (nem hivatalos)
- Xiaomi Smart Band 10 - a hetedik napon megpihen
- Keretmentesít a Galaxy S25 FE
- Telekom mobilszolgáltatások
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- MIUI / HyperOS topik
- Honor 200 Pro - mobilportré
- BlitzWolf termékek topicja
Ú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
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] -
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] -
#320
dezz
nagyúr
venember83
#316
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] -
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. -
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. -
dezz
nagyúr
Az teljesen nyilvánvaló, hogy azok ott nem gyakorlatias tesztek, nem is annak szánták, csak mindkét oldalon demonstrálják a worst és best eseteket. A gyakorlat meg valahol középen van. (Illetve még belejátszik a textúrázás is.) El lehet képzelni olyan kódot, ami ha nem is 5, de 2-3 független műveletet tesz lehetővé egyszerre.
gbors: ''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.''
Nem float5! ''float 5-instruction issue'' -> olyan kód, ami R600-on olyan VLIW utasításokat eredményez, amikben 5 különböző művelet van, scalar operandussal/-okkal. Ez az R600-nak ''meg sem kottyan'', de a G80 nagyon nem szereti.
''a float MAD serialnak a G80-on 170 körül illene lennie.''
Hát igen, de talán valami miatt nem lehet kihajtani az elméleti peaket.
R.Zoli: mint már próbáltam közölni, egy GPU nem tud minden feladattal megbírkózni, legalábbis úgy, hogy érdemes is lehet vele művelni.
[Szerkesztve] -
dezz
nagyúr
Olvasd el légyszi, amit a #262-esben írtam(*) neked erről! Nem csak a nyers FLOPS számít. Ja, kiadja majd a 7000 R600 (a 3-4 feladat-bonyolultsági kategóriából a legegyszerűbbet tekintve!), de mikor lesz 7000 olyan R600 tulaj, akik napi 24 órában foldingot futtatnak? Ugyanis az a 30000 PS3 az az aktuálisan foldingot futtató gépek száma az összesen ~128000-ből... Ehhez képest a GPU-val időnként résztvevők száma most összesen ~3200, amiből egyszerre most épp 940 megy, és ezek sem épp mind a legkomolyabb kártyákkal.
(*) Annyit még hozzátennék, hogy a G80 már sokkal inkább alkalmas a dologra, talán jön is majd ki rá kliens.
gbors: GF7 vs. X1: a másik esetet kevésbé ismerem, de ennél ugye az volt, hogy mind az 19xx, mind a 1650 igencsak későn jött, ezért túzott el az NV.
''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.''
Azt írják, hogy sehogy sem sikerült előcsalni, és hogy most vagy az interpolátor egységek működésének része (akkor végülis csak PR fogás volt külön emlegetni), vagy ott van, de a driverek jelen pillanatban nem használják ki.
''eztet nem értem. Mitől lenne 2x gyorsabb?''
100%-osan kihasználva a független superscalar végrehajtást 4x gyorsabb -> 50%-osan kihasználva 2x gyorsabb lesz. -
dezz
nagyúr
A 2-3 hónappal ezelőtt bemutatott, 2db CF-be kötött OEM R600-as kártyát tartalmazó setup pont 1 TFLOPS-os volt.
Az a 80-magos Intel cucc egy dolog (inkább csak érdekesség egyelőre), viszont nemrég indítottak egy komolyabb GPU-tervezési projektet is, amihez alaposan kibővítették a GPU-tervező gárdájukat is. Persze nyilván nem csak a GPGPU-s alkalmazásra hajtanak (hanem az AMD-hez hasonlóan takarékosabb irodai és mobil platform létrehozására is, bár ehhez eddig is megvolt ott a know-how, ha szerényebb GPU-s képességekkel is), de a hírek szerint erre is. -
dezz
nagyúr
Ha így nézzük, akkor ez az NV-nél ugyanolyan trend, sőt, ők voltak az éllovasai; azt hiszem, a gpgpu.org-ot is elsősorban ők segítettek elindítani, ott van a CUDA projekt a G80-hoz kötődően, stb. Az ATI az R600-zal két legyet akart egy csapásra (és ez nagyjából sikerült is). De szerintem a legjobb úgy nézni, hogy ezek nagy IT/ipari trendek, amikhez ezek a cégek vagy alkalmazkodnak, vagy elbuknak.
Az meg egy másik trend, ami az AMD nélkül is megy a maga útján, hogy a gaming fokozatosan egyre jobban átvonul konzolokra, mert ott jobban érzi magát (kisebb a kalózkodás, jobban megtérülnek a befektetések, kiszámíthatóbb a jövő, legalábbis több éves távon).
R.Zoli: RSX-en egyelőre nem megy a folding, mert olyan kliens nincs - egyátalán, GF-es kliens sincs, mert szerintük ilyesmiben kevésbé jók. Ha lenne is, felemás ez a dolog: egyszerű feladatokban gyorsabb egy GPU, a nagy nyers erő által, de összetettebb feladatokkal csak a CPU-k bírkóznak meg. A Cell meg a kettő között van félúton: egyszerű feladatokban sokkal gyorsabb, mint egy CPU, de fele/harmada egy GPU-nak, viszont közepes bonyolultságú feladatokkal is elbír, viszonylag gyorsan.
[Szerkesztve] -
dezz
nagyúr
Annak idején azért jelentős fegyvertény volt az Athlon 64 (32/)64-bitessége, még ha nem is igazán használták ki desktopon (Linuxosok azért jobban). Szerver és WS fronton már annál inkább számít, ha más nem, a nagyobb memóriaterület miatt. Más platformokon, mint Power és a többiek, már tudtommal kezdik el is felejteni a 32 bitet. Így szép is lenne, ha az x86-on nem lenne elérhető.
[Szerkesztve] -
dezz
nagyúr
Azért már egy ideje van mozgolódás GPGPU fronton, lásd pl. gpgpu.org. És a piaci szereplők is kezdenek felfigyelni a jelentős teljesítményre, relatíve olcsón. Persze bomba üzlet valószínű nem idén lesz, talán még jövőre sem. De valamekkora nyereséget valószínű azért realizálni tudnak majd hamarabb is.
ps. közben látom, a #254-ben inkább a gaming területére gondoltál. -
#255
dezz
nagyúr
Komplikato
#251
dezz
nagyúr
válasz
Komplikato
#251
üzenetére
''erre fel most meg AMD-t az ATI lártyáinak kéne megmentenie?''
Ezt így nem mondta senki (legalábbis rövid távon), de nyilván nem árt, ha az is hoz a konyhára.
''AMD-nek ha pénzt akar, akkor pöttyet fokoznia kéne a CPU fejlesztései sebességét''
Valószínű ennél jobban már nem is kokozhatná [szerk: akarom mondani fozozhatná - bár lehet, hogy kokóznak is
] - csak sajnos elég időigényes a dolog. De lényegében már kész van a köv. gen. (K10), most elvileg éppen indítják befelé a tömegtermelést.
Abu85: ''jó ötletnek tartanám a HyperTranszport 3 buszon hozzákapcsolt R600-at''
Hát igen, bizonyos feladatok nagyon igénylik a gyors adatcserét GPU és CPU között. Így valószínűleg pontosan ez lesz a következő lépés, még mielőtt a Fusion (egy lapkán CPU és GPU) megvalósul (45 v. 32 nm-en). Van is már hozzá platform: Torrenza (2 chipes, HT kapcsolatú rendszer, melyhez ipari szereplők számára megnyitották az AM2[+] foglalatot, és a HT3-at [illetve asszem ez eleve nyílt]). Bár ehhez le kell cserélni a PCIe interfészt az R600-on, és AM2 tokba tenni. Érdekes lesz.
rocket: ''Az AMD-nek nincsenek meg a megfelelo forrasai (anyagi, sw fejlesztoi), hogy ok diktaljak a jovobeni torteneseket''
Ezt mondták a 64-bittel (AMD64) kapcsolatban is, és láss csodát, az Intelnek kellett beadnia a derekát.
No de mindegy, a GPGPU dolog egy komoly IT trend, nem az AMD indította, de attól még meglovagolhatja.
[Szerkesztve] -
dezz
nagyúr
Gondolj arra is, hogy itt akár 6 különféle (5 math + 1 branch) művelet zajlódhat le, per blokk, per órajel(?). (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.) Egy PS-es kódban is elfér az...
Szerintem az R600 volt az egyik fő oka, amiért megvették az ATI-t - az R600 első nyilvános bemutatója is a GPGPU-s felhasználásról szólt. Ez egy gyorsan fejlődő terület, hamarosan a számításigényesebb feladatok többségét GPU-k fogják végezni, és persze itt is próbálja az AMD beelőzni az Intelt, akik szintén kezdenek foglalkozni a kérdéssel, ha kicsit kényszeredetten is. Meg persze az Nvidia is nyomul.
R.Zoli: ''Ha jönne egy optimalizált folding mondjuk R600-ra az sok mindent elárulna szerintem...''
Tuti jön.
''Csak nem tudom ebben mennyi pénz van ha ilyen célokra nyomják el a GPU-t...''
Szerintem komoly business (lesz, ha jobban beindul). Lásd hányszoros áron adja az NV a Quadrokat, ill. korábban az ATI a FireGL-eket. És azokat még inkább csak 3D grafikára használták. Ennél még sokkal magasabb a $/FLOPS arány a mini és szuperszámítógépek világában.
[Szerkesztve] -
dezz
nagyúr
Hát igen. (Így már értem, mire gondolt gbors.) Viszont az ilyetén, NV-féle stratégia egyben némileg vissza is tartja a fejlődést, mivel ugye választhatnak a fejlesztők, egyszerűbb kódot írnak, ami mindkét oldalon viszonylag jól megy (vagy R6xx-nál adott esetben kicsivel gyengébben), vagy összetettebbet, ami a G8x számára túlzottan megerőltető lenne. És persze nyilván inkább az elsőt választják.
-
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
Btw, itt van egy oldal, amin van egy új teszt-csoport (lap alja), ami különféle DX10 pixel shader kód-variációkkal teszteli a vasakat, így láthatóvá válik, melyik számára mi fekszik jobban, hogy viszonyulnak egymáshoz ezekben az esetekben, illetve hogy milyen potenciál van az R600-ban, ha a lehető legoptimálisabb kódot tudja (majd?) generálni a fordítójuk. [link]
-
dezz
nagyúr
Ja, értem. Akkor ha jól sejtem, ugyanazt a VLIW utasítást kapja meg az adott tömb 16 eleme, csak pl. más elem-indexszel (pixel, stb.).
Akkor viszont mit csinál az az - állítólag igen komplex - Ultra-Threaded Dispatch Processor? Azt gondoltam volna, az osztja szét az alapkód scalar és vectoros utasításait a 5+1 számoló és ugrási egység között, lehetőleg minnél optimálisabban. Úgy látszik, egyszerűen csak egy scheduler-féleség.
Akkor viszont igaza volt Abu85-nek, hogy ezt egy jó compilernek kell megtennie, és eleve így generálni a VLIW utasításokat...
[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] -
dezz
nagyúr
Lesz, de azokat már többnyire nem játékra veszik. A 7300GT meg nem is olyan rossz kártya (legalábbis a DDR3-as), de DX9-ben (akár ha csak a 9c-t nézzük), nem az a legkisebb játékra is nagyszámban használt kártya. (szerk: amúgy véletlenül shaderekben nem sokkal jobb akár a 8500?) Szerintem elmondható, hogy DX10 esetén jóval nagyobb rendelkezésre álló számítási kapacitással lehet számolni a játékkészítőknek. (+ a geom. shader.)
[Szerkesztve] -
dezz
nagyúr
Azért én ezzel egy icipicit vitatkonzék. (Most mielőtt valaki azzal jön, hogy majd pont én tutok vitatkozni egy Sweenyvel, olvasson tovább.) Szal, DX9c esetén a legkisebb kártya, amivel gaming szempontból számolni kell, az mondjuk egy X1300 v. GF6200. DX10 esetén viszont mondjuk egy 8500GT, esetleg egy eggyel kisebb. Tehát van némi különbség a kettőnél a bottom line teljesítményében, tehát DX10 esetén eleve nagyobb teljesítménnyel lehet számolni, amiből összetettebb dolgokat lehet összehozni. De ezen kívül DX10-ben ott van a geometry shader is, amivel ugyancsak érdekes hatásokat lehet majd előállítani.
-
dezz
nagyúr
''Szerintem emiatt van a 16-os SIMD jelleg.''
Igen, de én is ezt írtam.
''Érdekes az a megjegyzés, hogy egy ilyen tömb egyszerre 2 szálat tud vinni.''
Ezt viszont nem egészen értem, hogy ez honnan jön, és mi szükség rá.
Szerintem azért vannak kettesével párban az 5-way blokkok (amikhez így kapcsolódik egy textúrázó blokk is), mert könnyebb 2x5=10 számoló között kevesebb ''maradékkal'' (kihasználatlan egységgel) szétosztani egy vegyes (scalar + vec2..5) kódot, mint 1x5 között.
(szerk: de ha tényleg két szál fut 1-1 ilyen pároson, akkor nem kell osztozni a spec. funct. számolón, mert ugye a két blokkra jut 1-1 ilyen.)
Még egy érdekes különbség ugyebár a két arch. között, hogy - mint írtad is - G80-nál több, azonos szálat futtató blokk osztozik a textúrázókon, R600-nál viszont a SIMD tömb egyes ''sorai'', elemei teszik ezt -- miközben ugyancsak osztoznak ugyanazon a textútázó blokkon a többi SIMD tömb megegyező soraival. Hát, nem tudom, mit gondolja, ez jó vagy rossz. Ezt figyelembe véve talán lehet olyan kódot írni, ami nagyon nem fekszik az R600-nak...
[Szerkesztve] -
dezz
nagyúr
Abu85, rudi: ezt láttátok már? [link]
Ez 1-1 5-way superscalar blokkot mutat az R600 részéről, és egy 8-way SIMD blokkot a G80 részéről (ugyanis nem független az a 128 ALU, hanem 16db 8-way SIMD blokkból áll).
Nos, a G80 tényleg úgy hajtja végre a kódot ezeken, mintha scalar egységek lennének, de egyszerre 8 pixelre dolgozik egy ilyen blokk. (Tehát 8 pixelre ugyanaz a művelet.)
R600-on egy blokkon belül 5-way superscalarban hajtódik végre a kód, legyen az akár egy scalar utasítás, akár egy Vec2...5 utasítás. Ezt rendezi el szépen az a Dispatch Processor.
De itt jön egy csavar, az 5-way superscalar egységek 16-osával egy ''SIMD tömbbe'' vannak rendezve. Csak azt nem tudom, mit csinál ez a tömb SIMD-ként. Azt gondolnám, az G80-hoz némileg hasonlóan egyszerre 16 pixelre hajtják végre ugyanazt a kódot (szerk: vagy ha párosával ugyanazon a kódon dolgoznak a blokkok, akkor 8 pixelre), erre vonatkozik a ''SIMD'' jelleg. Ha így van, itt sincs semmi kihasználatlanság.
[Szerkesztve] -
dezz
nagyúr
válasz
Vistaboy
#166
üzenetére
''Érdekes eredmények, Én sem vártam volna hogy ekkora különbség van a két gyártó kártyái között, képminőség és sebesség tekintetében is.''
Jaj, de nehéz felfogni (főleg, ha a cikk is ''félreérthető''), hogy a 2900-ason jelenleg hibásan fut, nem egyszerűen csúnyábban és lassabban. -
dezz
nagyúr
Tényleg, vajon miért nem próbálták a 2900XT-n DX9-ben futtatni ezt a cuccot? Érdekes lett volna.
Na mindegy, az látható, hogy jelenleg hibásan fut a 2900-ason, ami szerintem driver-probléma, és nem pedig HW. Fogadni mernék, hogy ez nagyban változik majd, ha kigyomlálják. Bár el tudom azt is képzelni, hogy az nV ösztönzésére direkt rágyúrtak az R600 valamilyen szűk keresztmetszetére. (Viszont még azt is el tudom képzelni, hogy az is driver-probléma, mert azt már nehezemre esik elképzelni, hogy annyival gyengébb lenne néhány dologban, mint akár egy 1950.) -
#174
dezz
nagyúr
Interceptor
#167
dezz
nagyúr
válasz
Interceptor
#167
üzenetére
Igen, ezért fogalmaztam már úgy utóbb, hogy állítólag nem befolyásolta annyira (mely állítás a linkelt szövegben volt), mert rémlett azért 1-2 dolog.
-
dezz
nagyúr
Hogy értsd az egészet: az ATI-s ID csak azért kellett, hogy a fullos DX9 codepath fusson (mivel FX-en az túl lassú volt, így a Valve az FX esetén egy egyszerűsített kódot futtatott). Utána az FP24->FP16 patch ezt gyorsította fel - némi képminőség feláldozásával (de oké, mint már írtam, ez - állítólag - nem volt feltűnő). Azért jópofa, mit hoztak ki ebből egyes pár szóra korlátozott angol tudású egyének.
-
dezz
nagyúr
''és elhiteti a programmal, hogy márpedig ATI kártya van a gépben''
Kurv@ra nem ezt csinálta, ne terjessz már ilyen hülyeségeket! Az FP24-es kéréseket (amit az FX kénytelen volt FP32-vel kivitelezni) állította át FP16-ra, amit még elviselhető sebességgel tudott az FX. Csakhogy ez némileg befolyásolta a képminőséget (bár nem túl feltűnően). -
dezz
nagyúr
''1. It is prohibited to change the rendering quality level that is requested by 3DMark.
2. It is prohibited to detect 3DMark directly or indirectly. In its sole discretion, Futuremark may approve detection in order to fix a specified hardware error.
3. Optimizations that utilize the empirical data of 3DMark are prohibited.
4. Generic optimizations that do not violate the above rules and benefit applications in general are acceptable only if the rendering is mathematically consistent with that of Microsoft® DirectX® reference rasterizer.''
''Development of a truly impartial benchmark needs the input of all major players. We have spent the last few months talking with all the key hardware manufacturers and these common set of rules are the end result of this process. We will cooperate with all major graphics vendors to enforce the guidelines as quickly as possible.” [link]
Volt valami hasonló megállapodás, de a játékokat illetően is, a két cég részéről. Itt már fel lehet ismerni az adott játékot (eleve egy adott játék problémáit kell orvosolni is adott esetben), és annak megfelelő optimizációt aktiválni, végülis csak a képminőség megtartása a kritérium.
[Szerkesztve] -
dezz
nagyúr
Driveren belüli, az által megvalósított, az éppen futtatott app/game kóddal kapcsolatos optimizációról van szó: valamilyen módon elérik, hogy az adott HW számára optimálisabb módon vagy feltételekkel fusson.
Ez tehát különválasztandó az app/game kód készítők általi optimalizációjától.
Legális optimizáció: ami úgy valósul meg, hogy közben a képminőséget semennyire sem befolyásolja. Illegális: ennek az ellenkezője.
(#112) he7edik.: Lehet az egyik cég HW-ére külön optimalizálni az applikációs/game kódot, de szándékosan arra törekedni, hogy a másikon minnél rosszabbul fusson, plusz még hibásan is, az már más tészta.
[Szerkesztve] -
dezz
nagyúr
@Renwick:
''A Lost Planet demója feltűnően szebb és gyorsabb az NVIDIA DirectX 10-es vezérlőivel.''
''Szebb'' = hibamentes. Az 2900-ason hibásan futott a kód, pl. a hópelyhek helyett négyzetek jelentek meg. Teljesen nyilvánvalóan komoly driver-gond van.
''Az AMD szerint a vállalat szoftveres csapatát semmilyen az új demóval, és az abba integrált benchmarkkal kapcsolatos részletről nem tájékoztatták, így a fejlesztőknek nem állt módjukban kellőképpen „optimalizálni” az eszközillesztőket.''
Indokolatlan és téves idézőjelbe tenni itt az optimalizál szót. Akkor lenne indokolt, ha az optimalizálás valamiféle csalást jelentene, de szó sincs ilyesmiről (pár éve megállapodtak, mi fér bele a legális optimalizációba, és mi nem).
[Szerkesztve]
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ó. 
] - csak sajnos elég időigényes a dolog. De lényegében már kész van a köv. gen. (K10), most elvileg éppen indítják befelé a tömegtermelést.
Új hozzászólás Aktív témák
Hirdetés
- GIGABYTE GTX 1060 Mini ITX OC 3GB videókártya
- MSI GeForce VENTUS 3X RTX 3070 Ti 8GB OC GDDR6X 256bit videokártya
- ZOTAC GAMING GeForce RTX 3090 Trinity OC 24GB GDDR6X (6 Hónap Garancia)
- ZOTAC GAMING GeForce RTX 4090 AMP Extreme AIRO videókártya, garanciával eladó
- Asus ROG STRIX RTX 4090 EVA-02 Edition Videokártya!
- ÁRGARANCIA! Épített KomPhone Ryzen 5 5600X 16/32/64GB RAM RTX 5060 8GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Intel Core i9 9900KF 8 mag 16 szál processzor garanciával hibátlan működéssel
- Beszámítás! Sony PlayStation 5 825GB SSD lemezes konzol extra játékokkal garanciával hibátlan
- Xiaomi Redmi A3 64GB Kártyafüggetlen, 1Év Garanciával
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest