- A pápa egyre jobban tart a romlott AI veszélyeitől
- Milyen program, ami...?
- Windows 10
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Otthoni hálózat és internet megosztás
- Microsoft Excel topic
- Milyen routert?
- Az USA nem akarja visszafogni Kína növekedését
- Xiaomi AX3600 WiFi 6 AIoT Router
Új hozzászólás Aktív témák
-
kvp777
tag
Azért engem eléggé meglepett, hogy tipikusan játékra kitalált gépeket erre használnak az emberek.
Ez inkabb baleset. A sony egy tipikusan szuperszamitogepekhez kitalalt cpu-t rakott a jatekkonzolba. Tobbek kozott ez az oka, hogy ilyen szamitasokban jobb, es hogy lassan tobb hasonlo kliens lesz mint jatek. Programozni egyebkent naggyabol ugyanugy kell, mint egy mai gpu-t. (pl. az gf8800-asok 8 maggal, magonkent 16 egyseggel es 1.5Ghz-es orajellel rendelkeznek, mig a ps3-as cellek 6 szabad spe maggal, magonkent 2 egyseggel es 3.2Ghz-es orajellel rendelkeznek)
Egyebkent akkor fogjak a cell-ek spe-jeit kihasznalni, amikor a programozok vegre megtanuljak hogyan lehet a teljes jatekot shader-ekbol megirni, mivel a programozasi kornyezet nagyon hasonlo. (vagy valaki vegre kijon egy c++ -> cuda vagy c++ -> cell spe c forditoval)
-
kvp777
tag
"Programozni egyebkent naggyabol ugyanugy kell, mint egy mai gpu-t. (pl. az gf8800-asok 8 maggal, magonkent 16 egyseggel es 1.5Ghz-es orajellel rendelkeznek, mig a ps3-as cellek 6 szabad spe maggal, magonkent 2 egyseggel es 3.2Ghz-es orajellel rendelkeznek)"
Mint ahogy már többen megmondtuk neked különféle fórumokon, nem kellene blokkvázlatok vagy előadásokon nagy vonalakban elhangzottak alapján ilyen kijelentéseket tenned, talán kevesebbet tévednél.Ha nem tevedek ott voltal Peter Hofstee elodasan. (legalabbis egy angolul nem igazan tudo ember probalt a te stilusodban beszelni, vegul masok forditottak le a kerdeseit) Ha a cell tervezoje hasonlitja ossze a sajat processzorat a gf8800-as szeriaval, akkor neki erdemes hinni. Egyebkent en is az 1 cpu, 8 spe-s cell-t hasonlitottam ossze a 8 magos gf8800-assal. Mint az elhangzott lesz jobb valtozat is, bar ez a ps3-as embereknek szereny vigasz. (de majd a ps4 ha a sony tuleli a jelenlegi veszteseget) Latszott a tervezon hogy mennyire megtisztelonek erzi hogy rabiztak a feladatot es teljes erobol probalja a csapataval teljesiteni.
"amikor a programozok vegre megtanuljak hogyan lehet a teljes jatekot shader-ekbol megirni"
Minek is, amikor ott van egy PPE (Power Processor Element) mag is a game motornak?Mivel aki tud gpgpu-ra tisztan shader-bol jatekmotort futtato kodot irni, az a hasonlo architektura miatt fog tudni a cell-re is. Csak egy kulonleges cpu miatt nem tanul meg senki egy uj kornyezetet, de a gpu-k elterjedsege miatt elobb utobb minden ezen a teruleten dolgozo programozo meg fogja tanulni. Sokkal tobb gpu van a vilagban mint ps3-as konzol. (a regebbi dx9-eseket is beleszamolva)
"(vagy valaki vegre kijon egy c++ -> cuda vagy c++ -> cell spe c forditoval)"
Mire lenne ez jó? A C++-os kód fusson csak a PPE-n, az SPE-ken meg jó kis párhuzamosított vektoros kód. Nos ilyen vektorizáló fordítója van az IBM-nek.A hetfoi eloadas anyaga szerint ilyen lesz, de az is csak sima c-hez. Ez meg annyira nem elerheto technika, hogy az eloadas utan feltett egyik kerdesre az volt a valsz, hogy a gcc kodja szabad, arra megirhatja barki a hianyzo feature-t, majd atveszi az ibm ha tenyleg megeri. (jo van fortran is, de azt mar csak nehany oskovulet tudos hasznalja es az meg annyit sem tud mint a c)
Jelenelg a fordito csak overlay-eket tud kezelni, ami a dos-os turbo c-re volt jellemzo. Mivel a memoriamodell hasonlo, csak itt nem 4*64 Kb hanem 1*256 Kb az egyszerre cimezheto limit. Az overlay-ek legnagyobb atka, hogy a programozonak oda kell figyelnie, hogy eppen mi elerheto es mi nem. Ha a teljes dataset working set-je nagyobb mint a lokalis ram, akkor bonyolult lapozo algoritmusokat kell irni, csak arra, hogy hozzaferjen a program az adatokhoz. Ilyen algoritmusbol csak a bemutatott raytracing demo-hoz 7 kulonbozo kellett (+az ibm altal adott felkesz overlay kezelo a kodnak). Mindezt egy hagyomanyos processzor hardverbol tudja, ezert nem kell megirni minden egyes programhoz kulon-kulon. A devkit-nek jelenleg ugyanis nem resze, meg az ibm fele forditohoz sem adjak oket. (majd talan par ev mulva jo penzert... de most meg nem)
Szerintem erdemes lenne kb. a teljesitmeny felet feladva kesziteni egy altalanos interpretert, ami valamilyen virtualis cpu-t emulalna. (pl. .net kornyezetet) Igy a hianyzo hardvert a szoftveres emulator potolna, es jit-et hasznalva ez csak a teljesitmeny felet vinne el, viszont a virtualis kornyezet megegyezne az altalanos cpu-kkal. (a virtualis memoriat ugy lehetne emulalni, mint a mai szoftveres x86 emulatorok, ami lassu de konnyu programozni)
mas...
A cell egy spe-je magonkent ket egyseges vliw. Az itaniumok magonkent 4-6 egyseges vliw-ek. Az nvidia gf8800-asa magonkent 16 egyseges vliw. A legnagyobb ilyen rendszer magonkent (afaik) 16384 egyseges (egy CNND chip, ennel tobbmagosat meg nem lattam eloben). Az ilyen architekturak nagyon jok linearis vegrehajtasban, es nagyon rosszak elagazasban. Minel tobb alu van parhuzamosan annal nagyobb a veszteseg egy ugraskor. Az gf8800-as es az itanium ezt ugy kezeli, hogy van bennuk felteteles vegrehajtas. Ez azt jelenti, hogy egy if/else ugy fut le parhuzamosan ugras nelkul, hogy eloszor lefut az if ag, de csak azok az alu-k akitvak amikre evenyes a feltetel, majd lefut az else ag, a maradekkal. Egy bonyolult tobbszorosen egymasba agyazott if fat is at lehet alakitani egy bitmap-pe, ami akkor engedi a vegrehajtast ha az adott alura minden bit eppen 1 (az osszes feltetel igaz). Ezzel a megkozelitessel harom gond van, az egyik hogy bonyolut a fordito feladata, a masik hogy ciklusokat nem lehet vele rendesen kezelni, a harmadik pedig hogy egy if/else ag ketszer annyi ido alatt fut le mintha kulonallo vezerloegyseg lenne minden alu-hoz. (lasd x86-os pipeline-ok)
A gf8800-as nagyon jo minden olyan kodban amit ki lehet hajtogatni feltetelekre, viszont legrosszabb esetben 16-odara esik a teljesitmeny minden olyan esetben ahol eltero szamu ciklus kell, hogy lefusson, mivel ilyenkor a cuda fordito feladja es serializalja a kodot. Shader-ek eseten a jelenlegi directx architektura nem engedi meg egy polygon-on belul pixelenkent eltero shader programok hasznalatat, tehat ez a problema nem jon elo. Raytracing kozben viszont ez az alapeset, ilyenkor a gf8800-as jelenleg 128 magbol csak 8-at tud aktivan hasznalni. (blokkonkent 1-et) Ha 16 szalat osszefognanak egy kooperativ szuperszalla, akkor visszaterne a teljesitmeny, de ilyen forditoja jelenleg nincs az nvidia-nak. (a transmetanak volt, de az most az ibm tulajdona es nekik nem kell, mert egy cell spe csak 2 egyeges, amilyen a pentium I-es volt meg annak idejen, arra viszont meg a gcc is jo valamennyire)
Roviden szolva a jovo eleg nyitottnak latszik es nincs egyertelmu gyoztes. Ha az intel osszeszedi magat es kihoz egy 128 magos valosan fuggetlen cpu tombot, akkor letarolhatja a teljes piacot. (gyakorlatilag a gf8800-as teljesitmenyet hozna, viszont nem kellene optimalizalni a kodot, mert teljesen fuggetlen magokat hasznalna) Legjobb tudomasom szerint eppen dolgoznak egy ilyen megoldason. Az egyetlen nagyobb akadaly a memoria savszelessege lenne, de ha minden fuggetlen mag kaphatna egy sajat csatolot akkor ez is eltunne. A kerdes az, hogy ki foglalkozik jelenleg memoria es cpu szendvicsszeru osszeillesztesevel? (a valasz: a samsung es az intel, de vajon miert...)
ps: Mar keszulnek az optikai processzorok es halad a kvantumszamitogep is. Egyebkent en az optikai interferenciat hasznalo kvantumszamitogepeket tartom a jovonek (a feny is csak elektromagneses hullam), mivel ezek kepesek lehetnek szobahomersekleten is mukodni. Az elmeleti maximum egy skalar (1 'magos') optikai gep eseten tobb terahertz. (kb. a felhasznalt feny frekvenciajanak a fele) Egy hologramban tarolt rainbow table olvasasi ideje 1 orajel, mivel a feny parhuzamosan olvassa a teljes hologramot. Ilyen rendszeket mar most is tudunk kesziteni, csak a kiolvasott jel feldolgozasara (elektromos jelle torteno visszalakitasara) nincs jelenleg gyakorlatban is hasznalhato megoldas, bar egy lezer tartomanyban dolgozo felveteto cmos fototranzisztor feltalalasa megoldhatna a dolgot.
-
kvp777
tag
Jut eszembe, az előadás után közvetlenül, az ajtó előtt szúrósan rámnézett egy gonosz és féltékeny tekintetű srác, csak nem te voltál?
Nem. En rossz szokasom szerint eppen dumaltam. Egyebkent az itteni avatarom tokeletesen reprezentalja a hozzaallasomat a dolgokhoz. Nem kell versenyezni senkivel. A helyeztrol egy mondas jut eszembe: Az interneten vitatkozni olyan mint resztvenni a specialis olimpian, ha nyersz, akkor is bena vagy.
A gcc is C++ compiler. Bár oo kódot tudtommal csak a PPE-re tud fordítani, na de SPE-kre ki akar ilyet fordítani?
Az az oo kod a c++. A tobbi csak a sima c. Es szemely szerint en szeretnek standard template library-t hasznalni az spe-ken is. Ha egy texas dsp-n lehet es erdemes, akkor egy cell spe-en miert ne?
De mi a fenének kellene egy teljes játékmotort shaderekre írni? Vagy kizárólag SPE-kre?
Mert akkor lehetne pc-n (ahol nincs cell) egysegesitett grafikai es fizikai gyorsitas. Igy egy helyen lenne a grafikai adat es a fizikai rendszer. A physix legnagyobb baja, hogy lassan tud kommunikalni a gpu-val mert csak a cpu-n keresztul eri el, ezert sokaig tart amire a kiszamolt fizika kirajzolhatova valik. Ezzel szembe ha minden a gpu-n fut, akkor minden egy helyen van.
Azt nem tudom, mikor mit fognak adni, de az iRT-ről ezt írták valahol: The iRT now uses automatic code overlay support to switch shaders and read/write software caches to spill, sort, bundle, and evaluate secondary rays. These two coding features allowed the programming team to ignore the SPE's 256KB local store size for both code and data fetch and eliminated the need for programmer directed DMAs.".)
Leirtad ugyanazt amit en is mondam, csak most a google-t hasznalva. Az automatikus code overlay az az altalam is emlitett dos stilusu overlay kezeles. A read/write software cache pedig a 7 kulonbozo szoftveres adatlapozo konyvtarat jelenti, amit valakinek meg kellett irnia. Es az architektura miatt minden egyes adattipushoz kulon-kulon meg kell irni ujra es ujra. Az, hogy ok buszkek ra, hogy megirtak egy kulon konyvtarba nem jelenti azt, hogy ezt a hardver kezeli vagy hogy a fordito kepes lenne megirni a programozo helyett.
Rajta... De mégis, hogy gondolod pl. a memóriakezelést ezzel?
Lassuk csak... mondjuk szoftveres read/write cache-ekkel, amik automatikusan kezelik a virtualis lapok irasat, olvasasat es feldolgozasat.
És szerinted Linux alatt DX-eznek?
Nem, tobbek kozott ezert is szivas bizonyos dolgokat cuda vagy opengl alatt megirni. A gf8800-as nem szereti a dinamikus adatvezerelt elagazasokat. Kezeli oket, de 1/16-od teljesitmennyel. Gyakorlatilag csak 1 branch unit van blokkonkent.
Pontosabban ott nem tudhatna, ahol a pixel/vertex aktuális értékétől függ az ugrás. Ahol ettől független változótól v. ciklusváltozótól függ, ott persze igen.
Sajnos a tudomanyos felhasznalasban ez gyakori. A kozos, de eltero lepesszamu ciklusokat meg turkkozessel meg lehet csinalni, es ekkor a leglassabb vegrehajtasi ideje lesz az osszes ideje, de pl. az adatvezerelt felteteles ugras utani ciklusokkal mar nem boldogul, es nekiall egyesevel vegrehajtani.
remélem azt nem gondolod ,komolyan ,hogy a samsung lesz az Intel fő ellenfele ray tracing terén...Ott kő keményen Ati/AMD lesz az ellenfél...
Nem, a samsung az intellel egyutt szokott dolgozni, az egyik cpu-kat gyart a masik memoriat. Alapvetoen egyik sem er sokat a masik nelkul.
Na itt meg a Cell előnye jön ki, hogy nem ennyire széles a párhuzamosítás egy SPE-ben, hanem csak 4 elem széles a feldolgozás 32 bites adatnál - és azok is összefüggő adatok.
Igen, a cell-ek jobban hasonlitanak a hagyomanyos cpu-kra, leginkabb a 60-as evekbol szarmazo pic architekturara, annak is az eredeti formajara. (kis linearis cimter, fix orajeles utasitasok, relativ nagy sebesseg, interleave vegrehajtas, a kulonbseg hogy a cell nem harvard-os, bar az szerintem jobb lenne) A cell spe-k egyetlen hatranya, hogy altalanos cpu-nak hianyzik beloluk a virtualis memoria kezelese, vliw-es dsp-nek viszont nem eleg szeles az alu-juk. Valahol az intel fele altalanos cpu-k es az nvidia fele brute force-os buta vektoregysegek kozott vannak. Sem egyik, sem masik. Altalanos logikara jobb a cpu, vektorfeladatokhoz jobb a gpu. A cell-nek pedig maradnak a tudomanyos munkak, legalabbis amig valaki meg nem irja a szukseges virtualizalo forditot (lasd pl. compiled java) ugyanis jatekok eseten jelenleg minden programozonak fel kell talalnia a spanyol viaszt. Ahogy az eloadasban elhangzott, jelenleg sok mindent nem tud a fordito, de a gcc kodja nyilt, megirhatja barki. Ha egy jatekkeszito ceg embereit azzal biztatja az architektura kitalaloja, hogy eloszor irnia kellene egy hasznalhato forditot mielott elkezdene jatekot irni, akkor ez eleg hamar elveszi a kedvet az egesztol. Ilyenkor marad a pc, az xbox360 es a wii. Vagy alternativakent csak a power magot hasznalja. Ha egy multiplatform jatekot nem lehet egy altalanos cpu-ra irt koddal megcsinalni, akkor nem eri meg vacakolni egy amugy sem tul nepszeru konzollal. Meg az oskovulet wii-n vagy a ps2-esen is tobbet lehet eladni egy-egy jatekbol. Ha ma valaki jatekot akar irni sony-s konzolra, akkor a ps3 helyett erdemesebb a ps2-re dolgoznia, mert azt legalabb veszik.
-
kvp777
tag
Mivel ezt a PS3-mal kapcsolatban is csinálod, ezt már konkrétan FUD-nak nevezhetjük.
En probalok kedves lenni mindkivel, meg akkor is ha idegesito az illeto. Ez sok embernek sajnos nem sikerul. Egyebkent erdekes, hogy csak a PS3-al kapcsolatban veszed rossz neven a kritikat. Egyebkent amit irok az tobbnyire igaz. Ha esetleg tevednek, akkor korrigalast varnek el nem sardobalast. Ez az alap illem egyik fontos pontja fuggetlenul attol hogy ki mennyire ideges. (egyebkent en pl. miert lennek ideges? nem koltottem a penzem olyan hardverre amit nem tudok hasznalni es minden jatek fut a pcmen amivel jelenleg jatszani akarok)
"Es szemely szerint en szeretnek standard template library-t hasznalni az spe-ken is. Ha egy texas dsp-n lehet es erdemes, akkor egy cell spe-en miert ne?"
Nem tudom, most valójában lehet-e vagy sem, mindenestre ez nem egy létszükséglet tudományos és game területen. Javat nem akarsz rajtuk futtatni?Az stl keszitoi es elso felhasznaloi a tudomanyos teruletrol jottek. A jatekokat pedig ma mar tobbnyire c++-ban irjak, erosen megtuzdelve objektumorientalt script-ekkel. Mindkettonek feltetele a c++ tamogatasa. (egyebkent a java, a .net es a smalltalk nagyon kenyelmes nyelvek ha konnyen akarunk stabil programot irni)
Valamit valamiért: 10x-es teljesítmény némi pluszmunkáért cserébe. Ezt a dolgot nem sikerült megértened az előadáson?
Generacionkent 2x-ezodik a teljesitmeny. Ma a 4 magos cpu-knal jarunk, ez mar eleve 4x-es teljesitmeny. Egy mai x86-os munkaallomas 8 maggal dolgozik. (2x4) A leggyorsabb mai gyarhato hagyomanyos cpu 10Ghz-es, ez az ibm power magos processzora. Kb. ket even belul el elehet erni a mai cell teljesitmenyet, akar igazi technologiai valtas nelkul is, tehat ha ket evnel tovabb tart a program fejlesztese, akkor erdemesebb a jovobeni gyors x86-os cpu-kra dolgozni. (es meg optimalizalni sem kell semmit) Az uj 2 ppe-s, 32 spe-s power gyorsabb lesz es jobb (es vegre rendes ddr-es), de nem lesz annyival jobb, mint mondjuk egy 80 magos intel.
"Lassuk csak... mondjuk szoftveres read/write cache-ekkel, amik automatikusan kezelik a virtualis lapok irasat, olvasasat es feldolgozasat." Ehhez még nem kell virtuális proci.
Nem kell, de ha azt hasznalunk, akkor lehet ra irni jit-et es a mai forditoprogramok is tudnak ra dolgozni, arrol nem beszelve hogy a meglevo szoftverek ujraforditas nelkul is futnanak rajta. Keves munka -> sok haszon.
"A cell spe-k egyetlen hatranya, hogy altalanos cpu-nak hianyzik beloluk a virtualis memoria kezelese"
Nem azért hiányzik, mert elfelejtették beletenni. Tudod, valamit valamiért. Az előadáson erről is volt szó. Túl sok tranyóba kerülne (ez is többek között), és akkor szó sem lenne 8db SPE-ről.Kb. 64 huzalozott komparator regiszter es es par logikai kapu lenne az egesz. (4 KB-os lapok, 64 lapos L1 working set, exception driven software filled tlb) Ez jo esetben is csak par ezer tranzisztor, azaz kb. 500 byte-nyi local store. A 256 KB-hoz kepest nem jelentos. Persze a programozasi stilus nagyon megvaltozna, az spe leginkabb a sun niagara sorozatara hasonlitana.
"Valahol az intel fele altalanos cpu-k es az nvidia fele brute force-os buta vektoregysegek kozott vannak."
Nalátod. Akkor miért állítod be úgy, hogy szinte nem is különböznek az utóbbiaktól?Programozni ugyanolyan nehez oket.
"Sem egyik, sem masik. Altalanos logikara jobb a cpu"
Arra ott van a Cellben a PPE. (De ha szükséges, SPE-n is futhat, scalar adatoknál kb. 1/4 teljesítményen, ami azért még mindig nem olyan rossz.)A gf8800-asnal 1/16, ati-n 1/8-ad. Amennyivel jobb egy proci vektorfeladatokra, annyival benabb elagazasos logikanal. Programmed dynamic alu mapping pedig meg nem nagyon van. Azaz van, ha egy xilinx-be ezt tolti az ember. Lehet kapni viszonylag olcson 1 darab power maggal felszerelt, xilinx chipeket. Ezekben ki lehet alakitani annyi es olyan spe-t amilyet az ember megalmodik. Erdekes eredmenyeket lehet kapni vele. 4 ilyen, darabonkent 15 millios fejlesztoi kartyaval mar egesz szep gepet lehet osszehozni. Ha gyartasba kerulne, akkor persze sokkal olcsobban elo lehetne allitani, de ma magyarorszagon inkabb vesznek 100 kartyat 1.5 milliardert, mint hogy egy gyartosoron legyartassak, mert ez meg mindig olcsobb. (a lenyeg hogy szokott mukodni amit a cegnel hazilag osszerakunk) Lehet jobb cpu-kat is kesziteni, mint a cell. En szemely szerint az intel megoldasaban latok nagy jovot, felteve hogy ossze tudjak hozni. De otthon is osszedobtam mar egy-ket cpu-t, alacsony integritasu alkatreszekbol. (lomex-bol vett 20 eve porosodo chipek, prototipus panelen, kezzel forrasztva) A legjobb egy 20 Mhz-es 16 bites skalar cpu lett, bar sajnos nagyon bena az ugyancsak altalam tervezett videokartyaja. (de legalabb van benne linear frame buffer) Viszont szoveges konzol, debugger es 1 azaz egy darab grafikus demo van hozza.
"ugyanis jatekok eseten jelenleg minden programozonak fel kell talalnia a spanyol viaszt." Ez időről időre amúgy is megtörténik!
A mai nagy cegekre nem jellemzo az innovacio. Az oblivonban pl. csak a script-eket irta a keszito ceg. A terep, a novenyzet, a fizika, az animaciok es az arcmimika is mind keszen vasarolt modulokbol epultek fel. (ezert volt a legtobb bug a script-ekben)
A wow a legnepszerubb es egyben legkevesbe innovativ mmorpg. A jatekmotor alapja egy mud volt. Csakugy mint ahogy a diablo az open source nethack kodjat kapta, sajnos bugokkal egyutt. (a grafikus motor sajat gyartasu mindket esetben)
"Ahogy az eloadasban elhangzott, jelenleg sok mindent nem tud a fordito, de a gcc kodja nyilt, megirhatja barki."
Melyik fordító? A gcc-n kívül még van 2 c(++) fordító Cellre.Az ibm forditoja sem tudja a szoftveres smt-t, ami lehetove tenne a kooperativ multitasking-ot spe-n, ami lehetove tenne az external load/store rendszer (dma) rendes kihasznalasat. Igy a legtobb dma muvelet blokkolja az spe-t, a helyett hogy az masik task-ra valtana. A valsz az volt, hogy ha valaki megirja a gcc-hez, akkor berakjak a tobbi forditoba is. Mondjuk en fordito tamogatasa nelkul is meg tudnam irni assembly-ben, de a legtobb jatekot es tudomanyos programot ma mar nem assembly-ben irjak. Egyszeruen nincs ra ido.
"Ha egy jatekkeszito ceg embereit azzal biztatja az architektura kitalaloja, hogy eloszor irnia kellene egy hasznalhato forditot mielott elkezdene jatekot irni, akkor ez eleg hamar elveszi a kedvet az egesztol."
Ezek a dolgok könnyítik a munkát, de nem feltételei.A mukodo c++ fordito manapsag az egyik alapfeltetele a jatekfejlesztesnek. Sok ceg megtudja, hogy az spe-ken nem lehet objektumorientalt kodot futtatni virtualis memoriaban es inkabb elvetik az spe hasznalatat. (ezert van olyan keves ps3 exkluziv jatek) Ahol hasznaljak ott is tobbnyire az ibm vagy a sony kolcsonadott mernokei kodolnak az spe-kre.
1. Csak a legprimitívebb fejlesztők használják csak a PPE-t. Úgy kell nekik, ki kíváncsi rájuk.
Aki jatszani akar, es csak xbox360-ra meg vista-ra jon ki a kedvenc jateka. Az egyikben a hardver, a masikban a szoftver rossz. De mas valasztas nem nagyon van.
2. Sok kisebb adatcsomagokkal dolgozó rutin c kódja fordítható minden további nélkül SPE-re.
Igen, vegulis minden el kell hogy ferjen 256Kbyte-ban. Egy mai atlagos 1024x1024-es terkep pedig 1 Mbyte. :-)
3. Nagyobbaknál is sokszor elég egy egyszerű DMA kezeléssel kiegészíteni.
Kiveve ha 1 tombben van minden. Ekkor lehet nekiallni atirni mindent. A mai jatekok jo resze nagy tombokben tarolja az adatokat. (lasd terkepek, modellek, texturak, compiled vertex array-k, stb)
4. Butaság, hogy népszerűtlen: heti szinten átlagosan ugyanannyit adnak el belőle, mint Xbox360-ból. Csak az utóbbinak van 1 év előnye.
A wii-bol meg tobbet mint a masik kettobol, pedig nem sok elonye van.
5. A Wii egy más kategória, nem egyforma a törzsközönsége, mint a másik kettőnek.
Igen, wii-t meg talan en is vennek, bar inkabb halozati medialejatszonak es webbongeszonek. (olcsobb es jobb mint az apple tv) Jatszani inkabb pc-n szoktam. (keves a konzolos mmorpg, strategia es a szabadon moddolhato szerepjatek, pedig en ezeket szeretem)
ps: Roviden en nem a cell teljesitmenyet vitatom, csak az a velemenyem, hogy nem eri meg faradni azzal, hogy megtanuljuk programozni, mert a ps3 nem akkora piac. Mashol meg nem talalkozik az ember tul gyakran cell-lel. Persze szorakozasbol barki megtanulhatja, vagy azert mert penzt kap erte. Viszont a cegek jo reszenek nem eri meg a faradtsagot es a penzbeli befektetest. Esetleg majd a jovoben, ha mar jobb lesz a tamogatottsaga... de az jelenleg meg messze van.
-
kvp777
tag
Akkor miért nem hagyod békén a PS3-at? És miért propagálod állandóan az Xbox360-at? Minek avatkozol bele az egészbe?
Nem propagalom. A velemenyem az, hogy az xbox360 egy jo otlet amit nagyon rosszul rakak ossze. Egy egyszeru es olcso konzol lenne, ami a leheto legjobban hasonlit egy atlag windowsos pc-re, de sajnos annyira olcsora akartak csinalni, hogy kisporoltak belole a rendes hutest. Nem vennek xbox360-at mert rossz a hardvere es zart platform, de ps3-ast sem mert nincsen ra olyan jatek ami miatt nekem szemelyesen megerne, linux alatt meg le van tiltva a 3d gyorsitas. Viszont azt el kell ismerni, hogy az xbox360-as unified memory architecture-je sokkal kenyelmesebb es jobban skalazhato mint a ps3-as 3 fele elkulonitett memoriaja. (local stores, system ram, graphics ram) Nem jobb, hanem kenyelmesebb es konnyebben programozhato. Kevesebb ido alatt tobb jatek irhato ra.
"Az stl keszitoi es elso felhasznaloi a tudomanyos teruletrol jottek."
És? Matekos munkaállomásokon és szuperszámítógépeken nem éppen az oo-s kódolás dívik, hanem a vektoros.Az stl alapvetoen nem objektumorientalt, a c++-ra azert van szuksege hogy leforduljon, de mivel template gyujtemenyrol van szo, ezert barmilyen adattipusra jo. Egyik kedvenc stl-es komponensem a vector. Ennek hasznalata megfelelo implementacio mellett automatikusan optimalizalt vektoros/simd kodot eredmenyezne a template altal tamogatott muveletekre. Mindezek mellett kellemes dinamikus tomboket biztosit, ami az alap c-ben csak pointer-eken keresztul lehetseges, amik raadasul nem kepesek takaritast vegezni fuggvenybol valo vissztereskor.
"A jatekokat pedig ma mar tobbnyire c++-ban irjak, erosen megtuzdelve objektumorientalt script-ekkel. Mindkettonek feltetele a c++ tamogatasa."
Ha nem tévedek, ez leginkább a játék-logikára igaz, és azt Cellnél is lehet c++-ban írni, és a PPE-n futtatni.A c++ inkabb a grafikus motorra igaz. Pl. directx-et nem is nagyon erdemes mashogy programozni, mert az api c++-os. Egyszerueb konnyebb directx-re programokat irni, mint opengl-re. Ennek ellenere szerintem az opengl jobb, csak annyival bonyolultabb, hogy a legtobb programozo egyszeruen nem tudja hasznalni.
ja, és miért is (lenne) jobb a "rendes ddr", mint az XDR?
Sokkal olcsobb. Az eloadason is ez volt az egyetlen pozitivuma. En szemely szerint inkabb gddr-t raknek a cpu ala is. (mondjuk az xbox360 ezt is teszi, mar amikor eppen nem olvad ki a gpu a nyakbol)
"Kb. 64 huzalozott komparator regiszter es es par logikai kapu lenne az egesz. (4 KB-os lapok, 64 lapos L1 working set, exception driven software filled tlb) Ez jo esetben is csak par ezer tranzisztor, azaz kb. 500 byte-nyi local store. A 256 KB-hoz kepest nem jelentos."
Nem egészen, mert manapság már alap a memóriavédelem és a virtualizált memóriakezelés.Tehat fogjuk a 256KB lokalis ram-ot. Feldaraboljuk 4KB-os darabokra, minden blokknak adunk egy dedikalt asszociativ regisztert (egy komparatort). Ezutan a cimzes folso nem hasznalt bitjeit rakotjuk a regiszterekre, amiknek a kimeno jelei az adott blokkok enable jeleihez mennek. Ha nincs talalat akkor egy plusz nor kapu trap-et general egy fix cimre az elso blokkban. Igy a 256KB-os local store-t atalakitottuk 64 utas parhuzamos L1 cache-e, aminek 4KB-os a cache line-ja. Egyszerre 64 lap lehet a local store-ban. A lapok tolteset/menteset es a tlb kitolteset az elso blokkban futo kernel vegzi szoftveresen. Indulaskor a lapok a boot blokkra allnak be, mint most a digitalis alairas ellenorzesekor. (tehat ez nem igenyelne ujabb aramkort) Az egesz lehetove tenne, hogy minden cell kaphasson egy 4GB-os virtualis cimteret. Az spe cimtere es a rendszermemoria kozott tovabbra is szoftveresen menne a valtas, de a cimek helyenek ellenorzeset hardveresen oldanank meg. Ez az egyetlen muvelet amit minden cimzeskor el kell vegezni, tehat megeri hardveresen gyorsitani. Minden masra ott lenne a lokalis kernel az egyik blokkban. A vedelem es a strukuralt laptablak jelenleg is szoftveresen futnak pl. a sparc rendszereken. (ok is csak ez a sima tlb-t tettek be, csak mas a cache kiosztasa) A megoldasom masik elonye, hogy ha kesobb kijon egy 512KB-os local store-okkal felszerelt cell, akkor nem kell a kodot ujrairni, mert a blokk kezeles transzparens a kod szamara.
Ha így is van, némi asm keretrendszert kell elkészíteni, a többi már mehet sima c-ben.
Sajnos nem, mert a jelenlegi fordito nem tud relocatable kodot gyartani. Hiaba van keretrendszer ha a modulok agyonutik egymas regisztereit es memoriacimeit. Opcio meg nincs hogy megadjuk mettol meddig mehet egy modul. Ez konkretan kereskent elhangzott hetfon. (lasd: feature request)
Csúsztatás. A legtöbb multiplatform játék kijön PS3-on is.
Sot meg wii-re is, de jopar olyan van ami csak microsoft rendszerek alatt lesz. (xbox360 es vista) Van egy olyan fogalom is hogy directx exkluziv, amitol meg multiplatform de nem lesz ps3-as verzioja.
És most itt szerinted milyen relevanciával bír ez?
Annyival, hogy a kedvenc jatek kategoriaimbol 1 darab jatek sincs ps3 ala. Igy egyszeruen nem lenne mivel jatszani ha vennek egyet. Az emberek nem azert nem veszik mert draga, hanem mert nincs ra eleg jatek.
Hát akkor te ne foglalkozz vele...
Csak erdekelnek az uj architekturak, legyenek azok jok vagy rosszak. Eleg sok rendszerre fejlesztek egyszerre, erdemes latni mibol lehet valogatni. Pl. kepfeldolgozashoz a cell nem rossz, de azert ezen a teruleten siman veri a 8 magot egy 16384 alus digitalis cellular neural network processzor. (es azt is lehet kapni)
Egyebkent azt hiszem ezt a forumtemat magam reszerol lezarom, elegge elment a parbeszed fele, es szvsz. egy forumban nem ket embernek kellene leveleznie.
Új hozzászólás Aktív témák
it A konzolpiacon nem jeleskedik annyira a gép, mint a tudományos számításokban.
- Politika
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Futás, futópályák
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Tudományos Pandémia Klub
- iOS alkalmazások
- Kerékpárosok, bringások ide!
- A fociról könnyedén, egy baráti társaságban
- Háztartási gépek
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- További aktív témák...
- Díszdobozos Lenovo Yoga Slim 7i Pro "Kis Gamer" Ultrabook 14" -40% i5-11300H 16/512 QHD+ 2,8K OLED
- Ryzen5 esport Gamer(16gb ddr4/m2 ssd/win10/Vega11)
- HP ProBook 430 G6, 13,3" FULL HD IPS, I5-8265U, 8GB DDR4, 256GB SSD, WIN 10/11, SZÁMLA, GARANCIA
- Dell Latitude 3420, 14" FULL HD IPS, I5-1145G7 CPU, 8GB DDR4, 256GB SSD, W11, Számla, Garancia
- Dell Latitude 7280, 12,5" FHD IPS Kijelző, I5-6300U, 8GB DDR4, 256GB SSD, WIN 10, Számla, garancia