[SFIJ]

Idézet: bogdan - Dátum: 2007. jún. 12., kedd - 20:01

de ehhez mi koze az altalad idezett szovegresznek? (mert nem sok, azon kivul, hogy tobb lepcson es egyeb premisszan keresztul logikai/szemantikai kapcsolatot allitottam fel kozottuk.)

mi is volt az ertelme az idezesednek?

szerintem onmagad mevalaszoltad a sajat kerdesed. kellek en ehhez? :Ð

[dezz]

Idézet: Laa-Yosh - Dátum: 2007. jún. 12., kedd - 16:52

Ha nem egy adott képkocka adatait osztjuk szét, akkor az már nem a képkocka párhuzamos feldolgozása, konzolos környezetben pedig erre van szükség. Ott ugyanis szinkronizálni kell a tévé frissítésével, ami 30/60 fps kötelezõ betartását jelenti. Ha elkezdik szétbontani több tickre a képkocka feldolgozását, akkor az erõteljes késleltetést okozhat - eleve van egy adag az input miatt, a double buffering és vsync miatt, a tévé sebessége miatt, minden miliszekundum számít. Ezért ez a módszer nem járható út, hogy úgy párhuzamosítjuk a taszkokat, hogy a Cell fele az egyik képkockát számolja, a másik meg a következõt.

Nem értem, a kötelezõ 30/60 fps hogy befolyásolni a kérdést. Inkább azt gondolnám, a 30/60 fps alatti értékek elkerülése érdekében - konzolokra jellemzõen - mindent be kell vetni.

Vegyük pl. az alábbi szervezést:

épp megjelenített frame  számolt frame, feladat 1/2    számolt frame, feladat 2/2
-----------------------------------------------------------------------------------------------
          x (buffer A)              x+2 (buffer2 A)                  x+1 (buffer B)
          x+1 (buffer B)          x+3 (buffer2 B)                  x+2 (buffer A)
          x+2 (buffer A)          x+4 (buffer2 A)                  x+3 (buffer B)

(feladat 1/2: pl. fizika, feladat 2/2: rendering; buffer x: frame buffer; buffer2: fizikai számításokra)
Két fázisú futószalag, 2x-es gyorsulás, és pusztán 2 frame latency (a sima double-bufferezés 1 frame-jéhez képest). Az már túl sok lenne?
De nyugodtan lehet szólni, ha valami nem stimmel.

Idézet

Az alapkérdés pedig nem az volt hogy a Crossfire hogy mûködik, vagy hogy a futószalag mit jelent

Nem emlékszem, hogy azt mondtam volna, ezek voltak. De ugye látod, mégis hogy kapcsolódnak hozzá?

Idézet

hanem hogy a játékfejlesztõk milyen problémákkal szembesülnek a game kód párhuzamosítása során.

Igen, és ezért hoztam fel a lehetséges megoldásokra néhány példát.

Ezt írtad:

Idézet: Laa-Yosh - Dátum: 2007. jún. 11., hétfõ - 19:43

A játékoknál alapvetõen az a párhuzamosítási probléma, hogy a gameworld és renderer részfolyamatok mind egymásra épülnek - minden képkockánál fizikázni kell, AI-zni, game kódozni, aztán ez alapján animálni, renderernek parancsokat küldeni... A pontos sorrend játékonként változó, de alapvetõen mindig érvényes az elv, hogy az egyes fázisokat csak egymás után lehet indítani, párhuzamosítani ezek között nem nagyon lehet. Marad a folyamaton belüli többszálúsítás, ami viszont már jóval kevésbé egyértelmû, fõleg az SPE-k lokális memóriájának apró de annál fontosabb sajátosságai miatt.

Nos nekem úgy tûnik, nem csak a feladaton belüli többszálúsítás maradt.

Idézet

Az SPE-nek nagyon kevés az adat- és utasításmemóriája. Ezért nagyon kicsi taszkok gyors végrehajtására alkalmazható, és mivel gyors a busz, ezért nyugodtan lehet küldözgetni az adatokat - a probléma a késleltetési idõ. Ez jelentõsen megnöveli a várakozást, ezért érdemes bufferelni.

Ez azért némileg attól is függ, milyen filozófiával közelítjük meg. Gondolom, ismered a 96KB-os Kkriegert, vagy ott van a rengeteg 64k demo, amik nem egyszerû effekteket valósítanak megy ennyi kódból (tudom, tudom, a játékfejlesztõk nem ilyen "õrültek"). Na persze az adatok szempontjából több már jóval több ram kell nekik. Arra akarok kilyukadni, hogy ha elég jó a kód, nem magukat a taszkokat kell olyan sûrûn cserélni, hanem az adatokat. (Oké, ez már talán súrolja a kötekedés határát, bár ennek sem az volt a célja, de mindegy.)

[SFIJ]

Idézet: dezz - Dátum: 2007. jún. 12., kedd - 20:57

Vegyük pl. az alábbi szervezést:

épp megjelenített frame     számolt frame, feladat 1/2    számolt frame, feladat 2/2
-----------------------------------------------------------------------------------------------
             x (buffer A)                 x+2 (buffer2 A)                  x+1 (buffer B)
             x+1 (buffer B)             x+3 (buffer2 B)                  x+2 (buffer A)
             x+2 (buffer A)             x+4 (buffer2 A)                  x+3 (buffer B)

(feladat 1/2: pl. fizika, feladat 2/2: rendering; buffer x: frame buffer; buffer2: fizikai számításokra)
Két fázisú futószalag, 2x-es gyorsulás, és pusztán 2 frame latency (a sima double-bufferezés 1 frame-jéhez képest). Az már túl sok lenne?
De nyugodtan lehet szólni, ha valami nem stimmel.

Nem emlékszem, hogy azt mondtam volna, ezek voltak. De ugye látod, mégis hogy kapcsolódnak hozzá?

ez nagon szep, csa a vevoid letorik a kezedet. a szamolasi mododban (sajnos nem ketto, hanem) 3 frame-nyi ~50ms input lag-ed lesz a megjelenitett tartalom es a juzer altal eszkozolt akcio kozott. a HC gamerek mer 35-40ms lag eseten kurvaanyaznak...

raadasul a PS3-ban iszonyat memszuke van, ottvan meg a stencil/z-buffer kerdese is

Szerkesztette: SFIJ 2007. 06. 12. 21:49 -kor

[Laa-Yosh]

Idézet: SFIJ - Dátum: 2007. jún. 12., kedd - 22:44

3 frame-nyi ~50ms input lag-ed lesz a megjelenitett tartalom es a juzer altal eszkozolt akcio kozott. a HC gamerek mer 35-40ms lag eseten kurvaanyaznak...

Bibi #1: ez csak egy része a teljes lagnek.
Eleve ott vna az emberi reakcióidõ, ami ugye legalább 2-3 tizedmásodperc, ha jól emlékszem. A kontroller hw sem feltétlenül instant jelez a gépnek.
A képkocka végén várni kell a vsync jelre a kész kép kiírásához.
A legtöbb HDTV sem olyan marha gyors ám, pl. ha nem natív felbontásban hajtod akkor scale-ezni fog, ami szintén idõ. Ha hülye a user és bekapcsolva hagyja a zajszûrõket meg sharpen filtereket, akkor ez több tizedmásodpercre is felmehet... és persze ettõl a látvány kiesik a szinkronból a hanggal...

Bibi #2, és ez a nagyobb baj:
Manapság a 60 fps sebességgel futó játék szenzációszámba megy, Xboxon ilyen a Forza 2, PS3-on nem is nagyon tudok ilyenrõl. Akciójátékok a grafika miatt kivétel nélkül 30 fps-t érnek el (de akadoznak néha), ott 3 frame késleltetés pont 1/10-ed másodperc. Na az már önmagában túl sok... és akkor jön a többi késleltetés, és ebbõl lesz a csúszkálva és túl lassan reagáló, játszhatatlan játék.

Abszolúte elfogadhatatlan a játékoknál az, hogy akár csak egy képkocka plusz késleltetést hozzon a game kód. Csak az adott frame történésein belül lehet párhuzamosítani, ezért anyáznak miatta ennyire.

Szerkesztette: Laa-Yosh 2007. 06. 12. 22:19 -kor

[dezz]

Idézet: SFIJ - Dátum: 2007. jún. 12., kedd - 22:44

ez nagon szep, csa a vevoid letorik a kezedet. a szamolasi mododban (sajnos nem ketto, hanem) 3 frame-nyi ~50ms input lag-ed lesz a megjelenitett tartalom es a juzer altal eszkozolt akcio kozott. a HC gamerek mer 35-40ms lag eseten kurvaanyaznak...

Az a legrosszabb eset lesz (ha az éppen megjeleníteni kezdett frame elején jön az input [ami után még jön 2 frame számolás]). A legjobb meg 2 frame, 33,3 ms. Az átlag 41,6. Oké, ez sem a legjobb. Viszont, ez nem minden játékban számít ilyen sokat. Az ilyen szupergyors FPS-ek kedvelõi valószínû amúgy sem a konzolokat részesítik elõnyben, a maguk kikapcsolhatatlan vsync-ével.

Aztán ott van még az a lehetõség is, hogy pl. nem a teljes fizikát számolni az elsõ körben, hanem csak effekt-fizikát, amit nem befolyásol az input. Akkor kapásból visszatérünk a szokásos double-bufferingre jellemzõ késleltetéshez (1-2 frame).

Idézet

raadasul a PS3-ban iszonyat memszuke van, ottvan meg a stencil/z-buffer kerdese is

Na igen, de ez egy másik téma. Úgyanúgy el kell férni, akár így, akár úgy csináljuk a dolgokat.

Idézet: Laa-Yosh - Dátum: 2007. jún. 12., kedd - 23:15

Bibi #1: ez csak egy része a teljes lagnek.
Eleve ott vna az emberi reakcióidõ, ami ugye legalább 2-3 tizedmásodperc, ha jól emlékszem. A kontroller hw sem feltétlenül instant jelez a gépnek.

2-300 ms? Ehhez képest csak 16,6 (60fps) - 33,3 (30fps) ms, amit egy plusz fázis beiktatása okoz (ha input-függõ).

Idézet

A képkocka végén várni kell a vsync jelre a kész kép kiírásához.

Hát igen, PC-n (a legkülönfélébb videokártyák és monitor képfrissítési ráták közepette) úgy megy, hogy csinálunk valamit, aztán nekiállunk várni-várakozni a vsync-re... Konzolon meg jó esetben úgy, hogy az egész folyamat szinkronizálva van a vsync-kel.

Idézet

Bibi #2, és ez a nagyobb baj:
Manapság a 60 fps sebességgel futó játék szenzációszámba megy, Xboxon ilyen a Forza 2, PS3-on nem is nagyon tudok ilyenrõl. Akciójátékok a grafika miatt kivétel nélkül 30 fps-t érnek el (de akadoznak néha), ott 3 frame késleltetés pont 1/10-ed másodperc. Na az már önmagában túl sok... és akkor jön a többi késleltetés, és ebbõl lesz a csúszkálva és túl lassan reagáló, játszhatatlan játék.

Na hát igen, ez tényleg szomorú. (Utálom a 2-frémes frissítést.)

Idézet

Abszolúte elfogadhatatlan a játékoknál az, hogy akár csak egy képkocka plusz késleltetést hozzon a game kód. Csak az adott frame történésein belül lehet párhuzamosítani, ezért anyáznak miatta ennyire.

Hmm, itt ilyen többszáz ms késésekrõl van szó, akkor miért számít ilyen sokat ennek töredéke?

Szerkesztette: dezz 2007. 06. 12. 23:25 -kor

[Laa-Yosh]

Akkor adjuk össze, 30 fps mellett.

1. megjelenítési lag, amíg a kiküldött kép kikerül a tévére
legyen jóindulattal 10ms
2. játékos reakcióideje
250ms
3. kontroller reakcióideje
legyen megint csak jóindulattal 40ms

Eddig 300 ms telt el, ez 9 képkocka. Ha rosszul jön ki az input és csak a következõ frame-en értékeli ki a gép, akkor 10 képkocka. Ha atomgyors a játékos, akkor az mínusz egy kocka; ha átlagember, akkor plusz egy...

Ez után jön csak a feldolgozás, ami megint 2 vagy 3 kocka, tehát a legjobb eset most 8+2 = 10 kocka, a legrosszabb 11 + 3 = 14 kocka.

Megint output lag, megint reakcióidõ, legjobb eset 600ms azaz 18 kocka; legrosszabb eset 730ms.
Ez így már majdnem egy teljes másodpercnyi késleltetés aközött, hogy mi történt a játékban és mit csináljon rá válaszul a játék. Gyökér HDTV-vel akár az 1000ms is teljesíthetõ lenne. Borzasztó sok...

Szóval minden lehetséges eszközzel csökkenteni kell, és ebbe bizony beletartozik az is, hogy nem lehet gameworld eseményeket csak úgy több tickre elosztogatni. Már az is komoly kérdés, hogy a game kód - grafikai kód szétbontható-e egyáltalán - vagy az egésznek zusammen bele kell-e inkább férnie abba a 33.3ms-be...

[SFIJ]

Idézet: dezz - Dátum: 2007. jún. 12., kedd - 23:14

Az a legrosszabb eset lesz (ha az éppen megjeleníteni kezdett frame elején jön az input [ami után még jön 2 frame számolás]). A legjobb meg 2 frame, 33,3 ms. Az átlag 41,6.

úgyláccik nem programoztál még valós idejû szoftot. a jitter window-t mindig a worst case-re kell belõni. nem a game iparban dalgozom de van ebbõl gondunk, nemis kevés, nekünk is

mégegy apróság. LY a rekcióidõrõl beszél, énemeg az észlelésirõl. a rekció az, amikor látod, agyilag megcsócsálod majd nyomsz rá valamit. ez sokszorosa annak, mint amekkora lag már lehet zavaró. Én pl miniDV felvételen már az ajakszinkronon látom ha vacak a gép és a hang másfél két képkockát csúszik.  game seteében arról van szó, hogy nyúlás után a júzer élszleli hogy mennyiben változott a cuccos állapota. ez az idõ az input lag töredéke a rekcióidõnek. igazi HC gamerek CRTn jáccanak a mai napig mert a TFTk tipikus 1-2 framenyi lag-ja ismár zavaró a számukra.

Szerkesztette: SFIJ 2007. 06. 13. 00:27 -kor

[dezz]

Idézet: SFIJ - Dátum: 2007. jún. 13., szerda - 1:20

úgyláccik nem programoztál még valós idejû szoftot.

Nem egyet. 2D-s stuffok, double-buffering nélkül. A megjelenítés és az input polling 1 frémenként. (Illetve 1x-2x kellett némi mahináció az inputtal, ha nagyon rövid idejû pöccintésekre is figyelni kellett.)

Idézet

a jitter window-t mindig a worst case-re kell belõni.

Nem ismerem ezt a kifejezést.

Nem tudom, ma elégségesnek számít-e frémenként 1x utánanézni az inputnak, de ha igen, akkor én azt a köv. frame elõállításának elsõ lépésének tenném meg.

Idézet

Én pl miniDV felvételen már az ajakszinkronon látom ha vacak a gép és a hang másfél két képkockát csúszik.  game seteében arról van szó, hogy nyúlás után a júzer élszleli hogy mennyiben változott a cuccos állapota. ez az idõ az input lag töredéke a rekcióidõnek. igazi HC gamerek CRTn jáccanak a mai napig mert a TFTk tipikus 1-2 framenyi lag-ja ismár zavaró a számukra.

Hmm. (szerk: mondjuk én is gyorsan kiszúrom, ha valahol késik a hang, de még nem mértem le, hány ms fölött. Mostanában egyébként az m1-m2-n veszem néha észre, nem tudom, mit bénáznak.)


Laa-Yosh: Hát ez az, hogy azt gondolnám, 1000ms esetén 17-33 ms ide vagy oda már alig számít. De mindegy, inkább elhiszem, hogy nagyon is számít.

Szerkesztette: dezz 2007. 06. 13. 01:32 -kor

[dezz]

Ja, pár éve mikrokontrollerezek, ez is real-time, de frame-ek csak komm. protokollokban vannak. :Ð

[SFIJ]

Idézet: dezz - Dátum: 2007. jún. 13., szerda - 1:19

Mostanában egyébként az m1-m2-n veszem néha észre, nem tudom, mit bénáznak.)

nem biztos, hogy a z õ saruk. õk benyomják mamár ASI-ba. ezt átveszik a nagyadók meg a kábelesek. a kábelesek szépeb átcsomizzák low bitrate mpeg2-be, ezt szépen elküldik a fejegységeknek, a fejegységek meg visszaalakítják PAL-ba. a transcode/decode simán lehet 40-60 ms késleltetés. ha a hang delay rosszul van beállítva a transzkóderben, mindjárt kiló a lóláb

Idézet: dezz - Dátum: 2007. jún. 13., szerda - 1:19

Nem tudom, ma elégségesnek számít-e frémenként 1x utánanézni az inputnak, de ha igen, akkor én azt a köv. frame elõállításának elsõ lépésének tenném meg.

ez úgy megy hogy ugye az action csináz egy IRQ-t ebbõl lesz valami (win)message, bele a processz kjújába. rászagolsz a frame kiszámolásának az elején a kjúdra. namost ha a parszt véletlenül kicsit késõbb babrászott, akkor ezt az infót márcsak aköv frémben fogod látni digitális technika, nem tökéletes

Szerkesztette: SFIJ 2007. 06. 13. 03:17 -kor

[bogdan]

SFIJ-nek tisztelettel ajanlva:

http://www.renyi.hu/...sima-vektor.pdf

(ugy tunik ezek a magyarok, meg ha kulfoldon is publikalnak ragaszkodnak ehhez az elavult futoszallaghoz, meg ha butasag is.. mielott barki kerdezne a konyv angol eredetije 1997-es.)

[dezz]

10 év nagy idõ... Ma már a PC-s procik ált. ALU-i is átlapoltan fútószalagosak. A SIMD egységeik meg... valódi SIMD-esek. Hasonlóan,  a mai vektorprocik is full SIMD-esek (teljesen párhuzamosak) valahány bitig (128, 256, ?), és csak afölött jön be újra az átlapolásos futószalagosítás.

Btw, ideje lenne elismerned, hogy az SPE-k egyenként akár kvázi-scalar, összességében szoftver-futószalagos, más szóval felfûzött mûködtetésének semmi köze a fenti dologhoz - ergo, ami az említett módon megoldható, nem feltétlenül SIMD-esíthetõ.

Szerkesztette: dezz 2007. 06. 15. 17:01 -kor

[SFIJ]

Idézet: bogdan - Dátum: 2007. jún. 15., péntek - 16:23

SFIJ-nek tisztelettel ajanlva:

http://www.renyi.hu/...sima-vektor.pdf

(ugy tunik ezek a magyarok, meg ha kulfoldon is publikalnak ragaszkodnak ehhez az elavult futoszallaghoz, meg ha butasag is.. mielott barki kerdezne a konyv angol eredetije 1997-es.)

mar megint csuszttatsz futoszalagugyben, de nembaj. de azert olvass csak bele, itt egy cisc implementaciorol ir, es azt mondja, hogy egy ilyen cisc-be a futoszalag behozatala, akar ezerszeres eredmenyt hozhat. mig a valodi SIMD megoldas, multialuval, vagy particionalhato ALU-val tizeserszeres novekedest hoz.
de tovabra is ajanlom figyelmedbe a a wiki szocikket

egyre nyilvanvalobb szamodra, hogy az altalad preferalt istallo a DSPket hivja vektorprocinak - mi a vilag nagyobb resze nem

Szerkesztette: SFIJ 2007. 06. 15. 17:34 -kor

[bogdan]

Idézet: SFIJ - Dátum: 2007. jún. 15., péntek - 18:27

mar megint csuszttatsz futoszalagugyben, de nembaj.

oszinten szolva nem ertelek. hogy lehet csusztatni egy ilyen kerdesben, miszerint "van-e koze a futoszalagoknak a vektorprocesszorokhoz?", amikor az ember szakirodalmat hoz? hoztam magyar szakirodalmat (Nemeth-Horvath), nem tetszett Neked. OK. hoztam nagol nyelvut (Sima-Fountain-Kacsuk; mellesleg a Fountain irta az emlitett reszt), ez sem tetszik...

most ott tartunk, hogy en hoztam ket komolynak tuno szakirodalmat, Te meg meg mindig egy wiki cikkel dobalozol... (ami nem eleg pontos, es mellesleg emliti is a pipeline-okat..) kerlek hozzal valami komolyabb szakirodalmat, mert itt mar arra lenne szukseg. en ugy hiszem megtettem ezt.

Idézet

azert olvass csak bele, itt egy cisc implementaciorol ir, es azt mondja, hogy egy ilyen cisc-be a futoszalag behozatala, akar ezerszeres eredmenyt hozhat. mig a valodi SIMD megoldas, multialuval, vagy particionalhato ALU-val tizeserszeres novekedest hoz.

es? (mellesleg a futoszallag nem ezerszeres, hanem 10x-es szorzot hoz! olvass figyelmesebben..) nem az a kerdes, hogy ez a megvalositas mit er el mas elmeleti megkozelitesekhez kepest, hanem az, hogy amit anno es ma(!) vektorprocesszorkent arulnak, az vajon milyen felepitesu.

amugy meg egy idezet a konyvbol, "a futoszalagok alkalmazasai"-rol:
"Az elso alkalmazasi lehetoseg ugyanannak a muveletnek a sorozatos vegrehajtasa, mint peldaul, ket vektor egymast koveto elemeinek osszeadasa. A futoszalagtechnikat ily modon a vektorprocesszorok hasznositjak vektorutasitasok vegrehajtasara."

ez eleg egyertelmuenk tunik, nem?

Idézet

egyre nyilvanvalobb szamodra, hogy az altalad preferalt istallo a DSPket hivja vektorprocinak - mi a vilag nagyobb resze nem

a) nem preferalok en senkit! egyenlore ilyen szakirodalmat talaltam.
b) a vilag nagyobbik reszebe rajtad kivul ki is tartozik? hozhatnal vegre nehany komolyabb hivatkozast..,
c) ha ez a DSP, akkor a mai Cray es NEC vektorprocesszorok is DSP-k lennenek?? (kulonben mi a busnak emelnek ki a 8 pipeline-t az adatlapok?) nezd, SFIJ, egyre jobban ugy tunik, hogy nem egy orult megy szemben az autopalyan, hanem mindenki!!

**********************************************************

Idézet: dezz

10 év nagy idõ...

hat hogy is mondjam.. egyfelol azert a felsobb kategoriaban kicsit konzervativabb az ipar, kisse nehezebben fordul. itt nem egy-masfel evente cserelgetik az architekturat szemben az otthoni jatekosok igenyevel..

de en nyitott vagyok barmire! hozz nyugodtan frissebb szakirodalmat! (ahelyett, hogy orulnel, hogy a 15 evet mar 9-10-re leszoritottam ebbe kotsz bele? hm..)

Idézet

Ma már a PC-s procik....

vektorprocesszorokrol beszelunk, nem? nem PC-s megoldasokrol. irtam mar, hogy ne a PC-vel gyere. (a "valodi vektorprocesszor" kifejezes meg eleg vicces.. ez nem hittan, hogy a biblia megmondja, hogy mi a valodi..!)

Idézet

a mai vektorprocik is full SIMD-esek (teljesen párhuzamosak) valahány bitig (128, 256, ?), és csak afölött jön be újra az átlapolásos futószalagosítás.

hat tekintve azt, hogy az elso szerencsetlen Cray-1 is 4096 bites volt, egy mai vektorprocesszor meg.... ha az NCE-orl szolo wiki cikket nezem, akkor az talan 10Mbit szelessegu lehet..  szoval ez a "valahany bitig teljesen parhuzamosak" nem er tul sokat ebben. bosegesen kell am futoszallagokkal megtamogatni. (amugy meg miert erdekes ez? csak nem ugy gondoltad, hogy azt allitom, hogy tobbszorozesi technikat nem is hasznalnak a voktorprocesszorokban? persze, hogy hasznalnak! de futoszalagot is, nem is kicsit.)

Idézet

Btw, ideje lenne elismerned, hogy az SPE-k egyenként akár kvázi-scalar, összességében szoftver-futószalagos, más szóval felfûzött mûködtetésének semmi köze a fenti dologhoz - ergo, ami az említett módon megoldható, nem feltétlenül SIMD-esíthetõ.

a) meg egyszer mondom: valojaban nem az az erdekes, hogy a mai vektorprocesszork milyenek, hanem csak az, hogy bizonyos pipeline szamitasok ekvivalensek a vektorprocesszorokkal. (illetve, hogy ezek a bizonyos szamitasok igen gyakoriak.)
b) "nem feltetlenul"?? en soha nem mondtam azt, hogy "feltetlenul"!!! en csak annyit mondtam, hogy van olyan eset, amikor igen, es hogy ez az eset gyakori.

[SFIJ]

látom bogdán, nagyon rá vagy erre a pipeline dologra gyóygulva. tudod amit csinlász az kb olyan, mintha azt mondanád, hogy a budapesti bkv autóbuszok legfontosabb attribútuma az, hogy kékek. és való igaz, nem lehet elvitatni azt hogy kékek, de ha valaki nem látja be, hogy nem ez a legfontosabb tulajdonságuk... 

a további csuszákkal most nem foglalkoznék - nincs hozzá kedv :Ð

[bogdan]

hogymivan????
mikor mondtam en, hogy a vektorprocesszorok legfontosabb tulajdonsaga lenne a pipeline?? olvass mar vissza egy picit, mert ez a hozzaallas nem tul produktiv.

dezz allitotta, hogy nem azok (Te mellesleg csatlakoztal), en meg irtam, hogy marpedig de..

hogy jott ide a legfontosabb tulajdonsag? nem ertelek.

ha a tobbi "csuszka" is hasonlo szinvonalu.....

[SFIJ]

Idézet: bogdan - Dátum: 2007. jún. 16., szombat - 10:03

hogymivan????
mikor mondtam en, hogy a vektorprocesszorok legfontosabb tulajdonsaga lenne a pipeline?? olvass mar vissza egy picit, mert ez a hozzaallas nem tul produktiv.

dezz allitotta, hogy nem azok (Te mellesleg csatlakoztal), en meg irtam, hogy marpedig de..

hogy jott ide a legfontosabb tulajdonsag? nem ertelek.

ha a tobbi "csuszka" is hasonlo szinvonalu.....

pipeline ekvivalencia, hmm? :Ð

[bogdan]

kvazi ekvivalenciarol irtam, maradjunk is ennel.

[dezz]

Idézet: bogdan - Dátum: 2007. jún. 16., szombat - 9:42

hat hogy is mondjam.. egyfelol azert a felsobb kategoriaban kicsit konzervativabb az ipar, kisse nehezebben fordul. itt nem egy-masfel evente cserelgetik az architekturat szemben az otthoni jatekosok igenyevel..

Hát pedig de. Gondolod, hogy nem használják ki a technika új lehetõségeit? Mit is mondtál, hány pipeline lépéses az újabb nagygépek vektorprocijai, 256, 512, v. még több elemû vektorszámításoknál? 8? Na, ebbõl láthatod, hogy már itt sem elemenként hajtódik végre a dolog, hanem 32 (256/ elemet egyszerre dolgoz fel SIMD-ben... És így megy végig az összes elemen.

Idézet

vektorprocesszorokrol beszelunk, nem? nem PC-s megoldasokrol. irtam mar, hogy ne a PC-vel gyere.

A Cell SPE-it hova sorolnád?

Idézet

(a "valodi vektorprocesszor" kifejezes meg eleg vicces.. ez nem hittan, hogy a biblia megmondja, hogy mi a valodi..!)

CPU-k SIMD egységei: nem valódi vektorprocik, csak vektor egységek, erre vonatkozott a "valódi".

Idézet

hat tekintve azt, hogy az elso szerencsetlen Cray-1 is 4096 bites volt, egy mai vektorprocesszor meg....

64 (4096/64) lépéses pipeline hosszúságú volt?

Idézet

ha az NCE-orl szolo wiki cikket nezem, akkor az talan 10Mbit szelessegu lehet..  szoval ez a "valahany bitig teljesen parhuzamosak" nem er tul sokat ebben. bosegesen kell am futoszallagokkal megtamogatni.

Nem sokat ér? Csak 4x-es sebességnövekedést  (DP FP) 256 bitnél, 8x-os 512 bitnél, stb. Ha visszaolvasol, láthatod, hogy már én is írtam ezt.

Idézet

(amugy meg miert erdekes ez? csak nem ugy gondoltad, hogy azt allitom, hogy tobbszorozesi technikat nem is hasznalnak a voktorprocesszorokban? persze, hogy hasznalnak! de futoszalagot is, nem is kicsit.)

Hát... Erõsen úgy tûnt, ezt állítod. Az általad belinkelt irodalomban is a vektorprociban még nem volt valódi, egy idejû SIMD végrehajtás, azt csak a tömbprociknál említették... szerk: ezen hsz elsõ idézete tõled is éppen az, hogy nem változtatják olyan könnyen a jól bevált architektúrát (ami az irodalom szerint tehát full pipelined kellene legyen).

Idézet

a) meg egyszer mondom: valojaban nem az az erdekes, hogy a mai vektorprocesszork milyenek, hanem csak az, hogy bizonyos pipeline szamitasok ekvivalensek a vektorprocesszorokkal. (illetve, hogy ezek a bizonyos szamitasok igen gyakoriak.)

A nagyon régi vektorprocikkal - ha egyátalán volt valaha olyan, ami egyátalán nem tartalmazott valódi, egyidejû SIMD végrehajtást.

Idézet

b) "nem feltetlenul"?? en soha nem mondtam azt, hogy "feltetlenul"!!!

Dede. Ezt írtad: "(gy.k.: nincs olyan, hogy vektorizalni nem tudom, de futoszallagositani igen..)". (Mellesleg itt te instruction pipeline-ról beszélsz, miközben és szoftveresrõl, de mindegy.)

Idézet

en csak annyit mondtam, hogy van olyan eset, amikor igen, es hogy ez az eset gyakori.

Ezt gondold át újra... Még1x: az SPE-k felfûzásérõl van szó, melyek teljesen más kódsort hajtanak végre, és csak az eredményt adják tovább. Ez teljesen más dolog, mint a SIMD végrehajtás.

Szerkesztette: dezz 2007. 06. 16. 12:06 -kor

[dezz]

Idézet: bogdan - Dátum: 2007. jún. 16., szombat - 11:03

dezz allitotta, hogy nem azok (Te mellesleg csatlakoztal), en meg irtam, hogy marpedig de..

Idézz pontosan! Én azt mondtam, hogy ma már nem olyanok, és ezt utána pontosítottam arra, hogy bizonyos bitszámig nem olyanok. (És a végén még az is kiderülhet, hogy soha nem is voltak full pipeline-esek, hanem már eleve vegyes feldolgozásúak voltak.)