- Feljutott a G96 a Moto széria csúcsára
- Samsung Galaxy S20 FE - tényleg nem lite
- Kiszivárgott a Pixel 10 Pro
- QWERTY billentyűzet és másodlagos kijelző is lesz a Titan 2-ben
- Samsung Galaxy Watch7 - kötelező kör
- Milyen okostelefont vegyek?
- Na! Ez egy JÓ utólagos autós fejegység - Minix CP89-HD
- Szerkesztett és makrofotók mobillal
- 8300 mAh, maradhat?
- Android szakmai topik
Új hozzászólás Aktív témák
-
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] -
-
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
-
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] -
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? -
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. -
fagy53
nagyúr
-
#316
venember83
nagyúr
dezz
#313
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] -
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 -
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. -
-
Raymond
titán
''100%-osan kihasználva a független superscalar végrehajtást 4x gyorsabb -> 50%-osan kihasználva 2x gyorsabb lesz.''
Hogyan? Meg egyszer a felreertesek elkerulese vegett azert szogezzul le hogy ezek az elmeleti szamok:
HD2900XT 475; 8800GTX 345; 8800GTS 230 GFlops (a MUL-t nem szamolva). -
rocket
nagyúr
Jol ertem amit irsz akkor az a trend az amdnel, hogy nem foglalkoznak mar annyira hardver szinten a gamer tarsadalommal, mert szerintuk mas szegmenesekben sokkal nagyobb igenyek vannak ezekre az innovaciokra?
Az amd ezzel azt jovendoli, hogy hamarosan a konzolok fogjak atvenni a jatek pck szerepet, amit latvan az elmult idoszakot nem butasag, de meg messze van ennek a lehetosegnek a nagyszazalekos megvalosulasa, addig is elniuk kene valamibol. -
rocket
nagyúr
Az AMD-nek nincsenek meg a megfelelo forrasai (anyagi, sw fejlesztoi), hogy ok diktaljak a jovobeni torteneseket, persze mindig akadnak kivetelek a sw fejlesztok oldalan, de erre epiteni nem lehet ilyen fajta innovacioval.
Mig az NV az ''elj a manak, arasd le a baberokat kesobb'' elvet koveti az AMD megakarja valtani a vilagot innovacioban, amivel a kesesek miatt lassan arra se marad penzuk, hogy a fejleszteseiket finanszirozzak.
Elmult 2 evben nagyon sokat haladtak grafikailag elore a jatekok, de jol lathatoan a fejlesztok se birjak ezt az iramot amit digtalnak nekik a gpu gyartok, ezert van az, hogy 10 jatekbol 2 van amiben nincsenek jatekelmenyt befolyasolo hibak, amiket a masik 8-ban talan egyszer kijavitanak (nagyon sokszor sose).
A masik meg amikor csili-vili highend hardvereken szurok nelkul alacsony felbontasban vannak jatekok amik 25 frame atlagot ernek el, ha ennyire jovobemutato (optimalizalatlan inkabb) a jatek engine akkor inkabb tartsak a sufniban amig lesz hardver hozza, de nem errol van szo sajnos hanem nincs penzuk/idejuk/kedvuk foglalkozni vele tovabb mert a hype amit elore kialakitanak korulotte majd ugyis eladja.
Voltak jatekok amiknek folyamatosan csusztattak a megjeleneset, de amikor megjelentek tenyleg az akkori idokhoz kepest innovativ megoldasokkal voltak tele grafikailag, es nem voltak bughalmazok se.
Ha akarnak meg valamit AMD-nel a highend gpuk vilagaban, atkell szervezniuk a vezetoseget a grafikus chipek reszlegenel, ezzel a mentalitassal a sirba viszik magukat, felkell hagyni az ertelmetlen kinek nagy a ...., akarmom mondani kinek kisebb a csikszelessege vadaszattal, olyan gpu-t kell tervezni amit meglehet valositani idoben az akkori technologiakkal (anno a g80 megjelenes elott nem gondoltam volna 681 millio tranzisztort 90nm-en leghutessel meglehet valositani megis sikerult).
Az ATi/AMD belelepett a kutyagumiba az elmult lassan 2 evben 2x is, 90nm es most 80nm kapcsan, pedig most nem highendnel kezdtek meg az atallast (rv560/570), igaz ez egy teljesen mas architektura.
Kiszolgaltott az AMD/NV gpu szintem mivel egyiknek sincs sajat gyara (vagyis az AMD-nek van de egyelore az meg messze van barmit is csinaljanak a sajat gyaraikban gpu fronton), TSMC 80nm high speed nodeja csunyan leszerepelt az r600-zal, vagy talan az architektura tul komplex a 80nm-hez, nehez megmondani (megtudni sose fogjuk), mindenestre mindig beugrik a legeleso r600 pletykak egyike ahol azt ecseteltek milyen nehez lesz 80nm-en megvalositani az r600-at, talan amikor elkezdtek tervezni nem 80nm-ben gondolkodtak, azt gondoltak mire eljutnak a gyakorlati megvalositashoz mar gyerekjatek lesz a 65nm.
Most megerdekesebb helyzetben vannak mert anno az r520 utan helyre allt a rend az r580 kapcsan de ott nem kellett csikszelesseget valtani, mig az r650 ha 65nm-en jon raadasul ez ujratervezest igenyel nem csak egy kicsinyitese a 80nm-nek. (par shader,tmu,rop elkelne, meg ha valoban a shader level AA a hibas ROP-ok miatt van akkor ezt is kikell javitani).
Az tisztan kiveheto a tortenesekbol, hogy az ATi az r600-zat sokkal magasabb orajelekre tervezte, amit nem sikerult megvalositaniuk a gyakorlatban.
R600 meg teljesen az ATi gyereke volt, remelhetoleg az AMD mernokeivel karoltve visszaternek a helyes utra.
Osszegezve, rendet kell rakni ha akarnak valamit meg a highend vga piacon az AMD-nel, akarnak egyatalan? -
rudi
nagyúr
Hát, a fene tudja... Nekem úgy tűnik, hogy PS vonalon ezek az ''egyszerű'' float2 kódok mindenre elegendőek, ott nem látom, hogy float4 jellegű kódra kellene váltani. VS-nél és különösen GS-nél viszont már erőteljesen bejöhet a float4 formáció, de nagy kérdés, hogy ezek milyen arányban lesznek, lehetnek játék szinten a PS kódokhoz képest. Szép szöveg az, hogy a DX10 és az új ATI hardver esgítségével sokkal komolyabb geometriát és animációt lehet csinálni, csak nagy kérdés, hogy erre vannak-e erőforrásai (animátorai, 3D tervezői, ideje) a játékfejlesztőknek. Mert ugye OK, hogy egy Shrek szintű animáció most már akár PC-n, valós időben is reális, csak az adott játék eladásokból visszatárül-e az a sok munka?
A nagy DX10 hájpnak is el kell ülnie, hogy tisztán lássunk, és ott van még a másik oldal, a GPGPU-s. Lehet, hog az R600 már elsősorban pro clustereket verő számoló állatnak készült, amivel az AMD majd a nagygépes konkurenseket akarja csapkodni, és csak mellékesen használhatzó DirectX kód futtatására, a G80 meg egy ''játékchip''. -
rudi
nagyúr
Nekem az a fura, hogy a két architektúra annak ellenére mennyire eltérő, hogy elvileg ugyanarra a feladatra találták ki őket. Még korábban az ATI egyik sajtótájékoztatóján szó volt arról, hogy egy-egy új architektúra esetében komolyan mérlegelik, hogy mit érdemes és mit nem érdemes implementálni (asszem a VS textúrázás kapcsán jött szóva). Az ATI most nagyon sok mindent meg akart oldani, lehet, hogy ez lesz a veszte. Úgy tűnik, NV jelenleg az aktuális kódösszetétel sikeres végrehajtását tűzte ki célul, és talán majd akkor valósítanak meg komolyabb (vagy inkább más) dolgot, ha előkerül az alkalmazásokban. És innentől 22-es csapdája. Ha nem kerül elő, nem kell implementálni a hardverbe. Ha nem implementálják a hardverbe, akkor alkalmazásban sem kerül elő.
-
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. -
Raymond
titán
''Akkor viszont mit csinál az az - állítólag igen komplex - Ultra-Threaded Dispatch Processor?''
Amit a neve is mond - a szalakat iranyitja. Semmi koze az utasitasokhoz. A VLIW-esites akkor megtortenik mar mielott a kod a chip-be erkezik. Az a driverben talalhato shader compiler dolga. Az UTDP-be bejonnek a pixel/vertex/geometry shaderekhez tartozo thread-ek az pedig elosztja oket a 4 SIMD cluster-be. Egy cluster ket azonos tipusu thread-en dolgozik egyszerre. -
Raymond
titán
''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.''
Very Large Instruction Word. Egy darabban van a 6 utasitas ami egyebkent lehet barmi. A blokkban levo ALU-k csak 16x6 (5+1branch) csoportot kaphatnak meg es nem 80+16-ot. Muszaj csoportositani oket. Ha nem jon ossze az on-the-fly thread-ekbol akkor vannak a ''buborekok''. -
rudi
nagyúr
Egy kicsit pontosabb felvázolása a G80 architektúrának, ami a stream processzorok kapcsoltságát illeti [link]. Nem véletlen, hogy a blokk diagrammokon is 8 blokk van fejenként 16 (vagyis 8+8) processzorral. A textúra samplerek is így kapcsolódnak hozzájuk, szóval látatlanban mondható, hogy nem teljesen függetlenek (bár senki nem állította, hogy azok lennének).
Az R600-nál fejenként 16 barab 5 komponenses (összensen 80) számoló van egy tömbben, hozzájuk tartozik két-két arbiter és sequencer. Szerintem emiatt van a 16-os SIMD jelleg. Érdekes az a megjegyzés, hogy egy ilyen tömb egyszerre 2 szálat tud vinni. Ez talán éppen amiatt kell, hogy a 4+1-es blokk szükség eseténe (jelenlegi SM kódoknál elég gyakran) 2+2+1-es felállásban is tudjanak szálakat végrehajtani. Lehet, hogy amiatt van kihasználatlanság egyes shaderkódokban, hogy az a +1 komplex shader csak az egyik szálhoz társítható (vagy sok erőforrást igényel a váltogatása szálak között), szóval, ha mind a két szálnak kellene, akkor visszaesik a számolási sebesség. -
Abu85
HÁZIGAZDA
Mondjuk a CAPCOM annyira nem törte magát a hibátlan protáláson. A legtöbb gépen fagy, vagy el sem indul (nálam pl. a program szabálytalan műveletett hajtott végre). Szvsz erős a gyanum, hogy az NV erőltette, hogy gyorsan kiadják ezt a Beta izét. Ez lehet, hogy az nV-nek jól jött, de a Capcomnak nem, hiszen sokan a Demo alapján vásárolnak teljes játékot. Ugye miért vegyük meg az eredetit, ha már a demo fagy.
[Szerkesztve] -
#167
Interceptor
addikt
dezz
#155
Interceptor
addikt
tévedsz mert elég feltűnően befolyásolta.Épp azt próbálom magyarázni az embereknek hogy az Ati sohasem próbálta meg kicsinálni az nvidiát a színfalak mögött.Egyszerűen arról volt szó a HL2-esetében,hogy az Fx gané volt a valve viszont mindent megtett azért hogy dx9 alatt Fx-ekkel is viszonylag gyors legyen a gamma,igaz voltak képminőségbeli romlások,pl valahol csak fehér textúrákat láttam pl azokon a részeken ahol valamiféle dx9-es ficsőrt kellett volna hogy megjelenítsen.Köztudott volt hogy az fx-ek nem támogattak minden dx9-es effektet.Ez az igazság, tudom mert nem 2 db kártyával próbálgattam a HL2-őt.
-
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.
Csak a fene se tudta előre, hogy az melyik. No erről ennyit.
Majd elteszem az utókornak...
A kiemelt teszt kicsit(?) ferditi a valosagot annyiban hogy olyan keverek a gyakorlatban lehetetlen 
Eléggé kocka vagyok, de ilyenkor azért inkább alszom. 
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
- CPU léghűtés kibeszélő
- Alakul a Visa és a Mastercard európai ellenfele
- Kazy Computers vélemények - tapasztalatok
- AMD vs. INTEL vs. NVIDIA
- OTP Bank topic
- Épített vízhűtés (nem kompakt) topic
- Autós topik
- Milyen alaplapot vegyek?
- Hardcore café
- Feljutott a G96 a Moto széria csúcsára
- További aktív témák...
- 125 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 9 7945HX, RTX 4070 (ELKELT)
- Több mint 70.000 eladott szoftverlicenc
- Hp USB-C/Thunderbolt 3 dokkolók: USB-C Universal, G2, G4, G5, Hp Elite/Zbook- Thunderbolt 4 G4
- Bomba ár! HP ProBook 440 G10 - i5-1335U I 16GB I 256SSD I 14" FHD I Cam I W11 I Garancia!
- Bomba ár! HP ProBook 450 G10 - i5-1335U I 16GB I 256SSD I 15,6" FHD I Cam I W11 I Garancia!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest