-
dez #187 Na, asszem ideje válaszolnom.
"Szerintem inkabb probald ki. En is ezt tettem. Nagyon jo szorakozas... bar lehet hogy csak azert tunt konnyunek mert mar ismertem a forditot."
Mi tűnt könnyűnek? Lefordítani egy kisebb programot? Nem ez a nehéz, hanem a CUDA-t komolyabb célokra használni szándékozók szerint optimális kódot készíteni, ami nem csak fut, de értelmes sebességgel fut.
"A scatter-gather i/o pedig nagyon jol jon pl. raytrace-hez. De lehet alatta rendes grafikus/fizikai motorokat is irni, ahol minden latott polygon egy fizikai objektum resze, vagy dinamikusan valtozik a polygon-ok szama a kivant reszletesseg fuggvenyeben. (cpu beavatkozas nelkul)"
Kár, hogy ezeket még nagyon lassan viszi - lásd Geometry Shader teljesítmény a béka feneke alatt.
"Bar a local store-juk nem eppen szep, de mivel van rendes memoria i/o es smt ezert ez nem igazan szamit. (ha nem fer el az adat legfeljebb lassabb lesz a program, de mindenkeppen futni fog)"
Ja, legfeljebb 100x lassabb...
"Nem tudom neked mi az eleg, de egy gyakorlatban is hasznalt mintailleszto rendszerben 256MB volt a local store. (1 orajeles statikus ram-bol felepite) Az hozta a megfelelo teljesitmenyt, raadasul powerpc alapu rendszer volt. Egy mai jobb jatek mi vagy fizikai motor dataset-je neha nagyobb ennel, bar egy lepes soran nem dolgozodik fel az egesz. A baj az, hogy az algoritmus nem tudja elore mi fog kelleni neki."
2MB (8*256KB) már elég sok dologra elég.
"Talan mert sok cell-uk van raktaron es az nvidia bevetele nem az o hasznukat noveli?"
Hát ez nem egészen így ment, ugyanis akkor nem az IBM kapta volna a megbízást.
"A memoria fele mar nem olyan nagy a savszelesseg"
De igen, a memória felé ennyi. Az LS felé jóval gyorsabb.
"es a scatter gather i/o-t hasznalo algoritmusok igenis quadword-onkent akarnak olvasni."
Ez oké, de sokszor át lehet variálni a dolgokat. Nem emlékszel a múltkor hogy átalakítottam a példádat?
"En jatekra gondoltam elso korben. A ps3 alapvetoen jatekkonzol. Ha arra nem jo, akkor nem josolok neki tul fenyes jovot."
Majd meglátjuk néhány év múlve, jól gondoltad-e.
"Probaltad mar hasznalni az stl library-t cell spe-n? Es sikerult is?"
Még nem. De itt fordítókról volt szó, és azok vannak. (Én amúgy is mindent szeretek magam megírni.)
"Akkor ezert jobbak es van tobb linux-os jatek?"
Nem csak játékokról van itt szó.
"A cell-el az a baj, hogy az spe-k nem ugy mukodnek ahogy a vilag osszes tobbi altalanos cpu-ja teszi ezt egy ideje."
PC-s vonalon is jönnek majd a hasonló inhomogén chipek.
"Az ibm fele cucc jo resze open, tehat mashol is hasznalhato."
A kimondottan Cell-orientált dolgok nem igazán.
"Szerintem inkabb valami kesz kod jobb lett volna, mondjuk szabvanyos formaban. Hivhatnak felolem akar sony direct-opengl-nek is, csak ne techdemokbol allna."
Tudod, vannak a lusta programozók, és a nem-lusták. Az egyik összeollózik valamit kész kódokból, a másik a példákból megérti, mit hogy jó csinálni. Tudom, tudom, könnyed (multiplatform) fejlesztés, stb. Viszont ez egy konzol, nem egy Windows-box.
"Hanem hogy van? Mert kesz algoritmus meg egyelore nagyon keves van. Demok vannak, de eles project-ben ezek a kodok kapasbol buknak, mert nem szabvanyosak."
Lásd fent.
"De egy mai jatekban nagyobb az adatmennyiseg, es egy spe nem skalazodik felfele, mert a memorialimit bele van egetve az architekturaba. Legalabbis a ps3 cpu-jaba igen. Es ki akarna gpu-s shader logikat futtatni a fo processzoron? A szoftver renderelo mar kiment a divatbol."
A PS3 esetén legalább van erre kapacitás, az Xbox360-nál nem sok.
"Kb. ennyit rak az ember az otthoni barkacs hardverebe, hasonlo 1 orajeles sram formajaban. (mikrovezerlokben van kb. ennyi) Profi felhasznalasra mar tobbet szokas."
A GPU-kban még ennyi sincs, legalábbis a G80-ban az újak közül - az R600 valamivel jobban el van eresztve. Tehát még az újabb GPU-k sem többszörösen rekurzív kódokra, és más effélére vannak szánva.
"Ha meg olcson akarjuk meguszni akkor tobb lassabb egyseg es smt alapu thread valtas amig a kert adat megjon. Ezt hasznalja a gf8800-as."
Nem tudok róla, hogy az egyes egységek össze-vissza tudnának váltani a threadek között. Regiszterkészletből is annyi kellene.
"Meg a barkacs xbox360 is kapott 10 Mb nagyon gyors edram-ot, ami kb. az sram-ok szintjen van sebessegben, csak valojaban dram. Ilyet akar rakni az ibm az uj powerpc cpu-jaiba. A cell2-ben talan mar lesz is."
Az xbox360 esetén ennek felhasználhatóságe elég szűkös - és a nagy sávszél nem a GPU és az EDRAM között áll fenn, hanem csak az EDRAM-on belül, a ram és az ott lévő kisméretű logika között.
"Ha lenne, akkor nem az agyhalott dma rendszert hasznalna. Epp ez a gondom az egesz cell-el, hogy ezt az egy aprosagot kihagyak, mivel az spe nem tud sem hardveres smt-t, sem prediktiv memoria i/o-t, ezert a virtualis memoria kezeles csak lock-olna a teljes feldolgozast amig a lassu rambol megjon az adat, igy inkabb nem raktak bele."
Valami azért van, mert mindegyiknek van egy MMU-ja. Mindenesetre, 32 bitesek a címek, így ha máshogy nem, szoftveresen megoldható a lapozás. Ez persze lassú hétköznapi kód esetén, de lehet optimizálni rajta.
"Kis adatkeszletnel ez igaz. Ha elfogy a 256KB (kilobyte!) akkor jonnek elo a gondok. Azert ez mar nem egy olyan nagy adatmennyiseg hogy egy fizikai modell ne tartalmazzon tobb adatot. (es meg a programnak is bele kellene fernie)"
Nyilván bonyolódnak a dolgok 256KB (vagy kooperatív munka esetén 2MB felett), de sok esetben nem túlzottan.
"Probald ki! A linux eredetileg M68k-ra optimalizalt valtozata tokeletesen fut barmilyen memoriavedelem nelkuli rendszeren, bar driver nem nagyon lesz hozza, de vegulis csak egy shared memory alapu driver stack kell neki (csomag i/o alapu virtualis hardverekkel, amiket a kulso cpu kezel). Last nommu-s kernel. A kod egyszalu resze nagyon lassu lesz, de a parhuzamos feldolgozas sokat nyer a 128 maggal."
Az "általános CPU" azt jelenti, hogy általános kódot értelmes sebességgel futtat. A G80 erre nem képes, csak nagyon lassan. Nagyon is specializált rendszer. A gyosítás nem egyszerű párhuzamosítás, hanem sok kötöttségre kell odafigyelni.
"Van mar devkit-ed? Ha nincs vetess a cegeddel egyet es megerted miert kap hulyet tole a legtobb fejleszto."
Jelenleg megbízásos magánzó vagyok, szal max. magam vehetek egy PS3-at, és szórakozhatok Linux alól.
"Mutass egy ceget magyarorszagon ahol ps3 exkluziv fejlesztes van es eppen van felvetel rendes fizetessel... egyszeruen a ps3 exkluzivitas nem jellemzo a mai cegekre. Mindeki csak egyszer ir es sokszor fordit. Mondjuk ez az eladasok tukreben ertheto."
M.o. kis ország - a világon máshol azonban vannak ilyen fejlesztések. És ahogy beindul a szekér, több is lesz.
"Egyebkent meg en teljesen tisztaban vagyok azzal, hogyan lehetne jo kodot irni a cell-re. Jol szegmentalhato adatmodell kell, vektoros feldolgozas, manualis memoriakezeles, es buta, de gyors cpu-t igenylo algoritmusok. Az egyetlen gond, hogy egy ilyen kod nem futna jol mas cpu-kon. Ha egy ceg valaszthat, hogy fejleszt az osszes tobbire vagy ps3 exkluziv lesz, akkor az elsore fog tenni. Es meg tobbet is adnak el az osszes tobbi gepbol (pc, xbox360, wii) tehat tobb jatekot is fognak rajuk venni."
A PS3-mal viszont különlegesebb dolgokat lehet csinálni, és ha megjelenik 1-2 ilyen, az jó hatással lesz az eladásokra is - utána megéri majd több ilyet fejleszteni.
"===Mas==="
Egyszerűbb lenne használni a "válasz erre"-t (akkor a visszakövetés is könnyebb), és személyesen válaszolni.
"Majd jopar ev mulva mar lesz rendes tamogatas, de addigra elavul a cell."
A PS3-ban lévő igen, de közben lesznek újabb Cellek is, több+okosabb PPE-vel, SPE-vel, LS-sel.
"A hagyomanyos algoritmusok pedig cpu-tol fuggetlenul barhol jol fognak futni a jovoben is, mig a cell-re optimalizaltak csak a cell-eken."
Mint írtam, PC-s vonalon is jönnek majd a heterogén chipek (náhány sima CPU mag, és jópár SIMD-alapú mag). (Poén lenne, ha azok is DMA-sok lennének a jobb helykihasználás érdekében. :P)