Keresés

Új hozzászólás Aktív témák

  • dezz

    nagyúr

    válasz kvp777 #40 üzenetére

    "A sony egy tipikusan szuperszamitogepekhez kitalalt cpu-t rakott a jatekkonzolba."
    Hát nem egészen, mivel ott nem a performance/watt, performance/transistor arányok a legfontosabbak. A Cellt egy univerzális chipnek szánták, ami jó oda is, de munkaállomásokba, médiacenterekbe, és pl. játékkonzolokba is.

    "Tobbek kozott ez az oka, hogy ilyen szamitasokban jobb, es hogy lassan tobb hasonlo kliens lesz mint jatek."
    Nem éppen. Egy játék fejlesztése kicsit hosszadalmasabb, mint egy ilyen kliens portolása, némi optimalizációval. A másik persze, hogy ez egy többmagos, ráadásul inhomogén proci. De ez másféle alkalmazások fejlesztését is nehezíti (cserébe viszont igen nagy teljesítményt lehet belőle kihozni).

    "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. :U

    "Egyebkent akkor fogjak a cell-ek spe-jeit kihasznalni"
    Mint azt is megmondták már neked, jópár játék használja már őket (több-kevesebb optimizációval). Más területekről nem beszélve.

    "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? :U

    "mivel a programozasi kornyezet nagyon hasonlo."
    Aha, 10km magasból nézve. (Attól, hogy némileg jobban hasonlítanak egymásra, mint egy hétköznapi CPU-ra, még nem lesznek hasonlók.)

    "(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.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz kvp777 #52 üzenetére

    Na most vagy hazudsz, vagy magad nem tudsz eléggé angolul.
    1. Az összes kérdésemet magam mondtam el, Hofstee meg is értette, és szépen válaszolt is rájuk. Érdekes nem? :U
    2. Utána még akartam egy apróságot mondani lezárásként, és egyetlen szó (elhivatottság) nem jutott eszembe. Az előttem lévő sráctól kérdeztem meg, viszont úgy tűnt, neki sem jutott eszébe, ezért megpróbálta a saját szavaival elmondani (nem nagyon sikerült azt mondania, amit én akartam, de mindegy).
    3. Az előadás után váltottam még Hofstee-vel néhány szót, megkérdeztem, értette-e, amit a végén mondani akartam, és mondta, hogy tökéletesen. Meg is köszönte a kommentjeimet.

    Tudod mit, ezek után kurvára nincs kedvem tovább olvasni az irományodat.

  • dezz

    nagyúr

    válasz kvp777 #52 üzenetére

    Na asszem mégis kénytelen vagyok válaszolni.

    "Ha a cell tervezoje hasonlitja ossze a sajat processzorat a gf8800-as szeriaval, akkor neki erdemes hinni."
    Éppen arról beszélt, hogy a GPU-k sok számítási feladatra sem optimálisak, ellentétben a Cellel. Te meg úgy akarod itt beállítani, hogy szinte egyformák... Nem érzel itt egy kis különbséget?

    "Mivel aki tud gpgpu-ra tisztan shader-bol jatekmotort futtato kodot irni, az a hasonlo architektura miatt fog tudni a cell-re is."
    De mi a fenének kellene egy teljes játékmotort shaderekre írni? Vagy kizárólag SPE-kre?
    Nem véletlenül van ott az a PPE sem.

    "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)"
    Te most miről beszélsz? IBM XL C/C++ for Multicore Acceleration for Linux
    A high-performance IBM XL C and C++ compiler for the Cell Broadband Engine Processor.

    A Cell SDK része, bár beta verziós.
    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?
    (Továbbá ott van még az IBM Octopiler nevű fordítója, ami automatikus párhuzamosító és vektorizáló. Bővebben.)

    "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)"
    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.".)

    "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)"
    Rajta... :D De mégis, hogy gondolod pl. a memóriakezelést ezzel?

    "Az nvidia gf8800-asa magonkent 16 egyseges vliw."
    Az R600-as a vliw alapú.
    The G80 shader core is a little different from the R600. It is built on eight SIMD units each containing 16 SPs. The SIMD instructions are not VLIW, but single scalar instructions, and each SP within a SIMD unit executes that instruction on a different thread. While groups of 16 SPs share resources, NVIDIA's compiler doesn't need to build VLIW instructions to schedule out any of these SPs and it would be quite difficult to create dependencies between SPs because they are running different threads. [link]

    "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."
    Izé, ez itt a Static Flow Control, ami már DX9.0-ban is volt, vagy még előbb. DX9.0c óra van Dynamic Flow Control is, ami ugrásokat is kezel. Kicsit frissítsd az ismereteidet.

    "Shader-ek eseten a jelenlegi directx architektura nem engedi meg egy polygon-on belul pixelenkent eltero shader programok hasznalatat"
    És szerinted Linux alatt DX-eznek?

    "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)"
    Azt már a 80-magos TeraScale-jével is alaposan lenyomná. De még talán a 16-24 magos Larrabee-vel is. Tudod, mag és mag között lehetnek nem kis különbségek.

    "Egyebkent en az optikai interferenciat hasznalo kvantumszamitogepeket tartom a jovonek"
    Hát nem tudom, tudod-e, hogy működnek a kvantumszámítógépek, de az interferencia általában az ősellenségük. De lehet, hogy te felfedeztél valami sokkal jobbat, ki tudja. ;)

  • R.Zoli

    őstag

    válasz kvp777 #52 üzenetére

    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...

  • dezz

    nagyúr

    válasz kvp777 #67 üzenetére

    "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."
    Az a baj, hogy ezzel a "beszéljünk jó sokat össze-vissza, a fele csak igaz lesz" filozófiával jópár embert felidegelsz, akik nem igazán örülnek, ha valaki téves információkat terjeszt, helyessel keverve, így megbízhatónak tűnően. Mivel ezt a PS3-mal kapcsolatban is csinálod, ezt már konkrétan FUD-nak nevezhetjük. És ez ellen kénytelen az ember fellépni.

    "Az az oo kod a c++. A tobbi csak a sima c."
    Igen - ki írt mást?

    "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?

    "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 teljes játékmotorról volt szó, amibe beletartozik a játék-logika is, és az lett volna a lényeg. Az meg a procin érzi jól magát, és nem is akarja senki elmozdítani onnan.

    Az persze természetes kívánság, hogy a grafika, fizika, AI (nagyrészt) a GPU-n, ill. PS3-nál részben azon, részben az SPE-ken fusson. Azonban ez perpill PC-n nem igazán kivitelezhető, mert 1. GPU limitesek a játékok, tehát nincs fölös GPU-kapacitás. 2. A többmagos procik meg többnyire kihasználatlanok. Mondjuk valószínű a későbbiekben egyszerűen kénytelenek lesznek GPU kapacitást áldozni erre (mármint fizikára, AI-ra), mert egy kis GPU idő sok-sok CPU idővel ér fel, azaz egy fél GPU többet tud fizikázni, mint több CPU mag. De egyelőre nincs is ennyi fizika a játékokban. Azonban, láthatóan a dolgok affelé haladnak, ami a PS3-nak is kedvez. Erre te csak kántálod tovább, hogy nincs jövője, bla bla bla.

    "Leirtad ugyanazt amit en is mondam, csak most a google-t hasznalva."
    Nem kellett használnom a google-t, mivel hetekkel ezelőtt olvastam azt a szöveget, amiből az idézet származott. (Más okból már máshová is betettem.)

    "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."
    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?

    "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, 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."
    1. Épp az imént írtad le, hogy a statikus flow controlnál sem jobb a helyzet, szóval azt sem szereti.
    2. Lényegében vehetjük úgy, hogy az R600-nál meg 8 blokkonként van 1, mert úgyis egyszerre működnek (ugyanannak a szálnak az utasításait hajtják végre, 1-5-ösével).

    "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)"
    Már úgy érted, az SPE-k? Nem tudom, hogy jön ide a PIC (jah, némi távoli hasonlóság van), az SPE-k leginkább SIMD procikra hasonlítanak (illetve x. generációs vektorprocikra).

    "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.

    "vliw-es dsp-nek viszont nem eleg szeles az alu-juk."
    Ez miért olyan nagy baj?

    "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?

    "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.)

    "vektorfeladatokhoz jobb a gpu."
    Ha leginkább csak nyers erő kell, akkor persze jobb a GPU. Más feladatnál nem feltétlenül.

    "A cell-nek pedig maradnak a tudomanyos munkak, legalabbis amig valaki meg nem irja a szukseges virtualizalo forditot"
    Nem igaz, mert már ma is úgy fejlesztik a legtöbb játékot rá, hogy többé-kevésbé igénybe veszik az SPE-ket is! Ezt már aktuális játékfejlesztő is mondta neked, szóval vedd végre tudomásul.

    "(lasd pl. compiled java)"
    Ugh, szóval mégiscsak javát akarsz rá... :DDD Ez az, tizedeljük csak meg a teljesítményét, legalább nem lesz gyorsabb, mint egy sima proci. :P

    "ugyanis jatekok eseten jelenleg minden programozonak fel kell talalnia a spanyol viaszt."
    Ez időről időre amúgy is megtörténik!

    "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.

    "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.

    "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."
    Na, ez meg a már tőled megszokott PS3-bashing bla-bla. :U
    1. Csak a legprimitívebb fejlesztők használják csak a PPE-t. Úgy kell nekik, ki kíváncsi rájuk.
    2. Sok kisebb adatcsomagokkal dolgozó rutin c kódja fordítható minden további nélkül SPE-re.
    3. Nagyobbaknál is sokszor elég egy egyszerű DMA kezeléssel kiegészíteni.
    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.
    5. A Wii egy más kategória, nem egyforma a törzsközönsége, mint a másik kettőnek.

    ps. valamiről még megfeledkeztél.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz kvp777 #69 üzenetére

    "En probalok kedves lenni mindkivel, meg akkor is ha idegesito az illeto. Ez sok embernek sajnos nem sikerul."
    Nézd, most elsősorban te idegesítesz fel másokat a féligazságok tényként előadásával. Műszaki körökben a féligazság egy kalap alá tartozik a hazugsággal. (Bár máshol is így lenne...)

    "Egyebkent erdekes, hogy csak a PS3-al kapcsolatban veszed rossz neven a kritikat."
    Nem, a kritikát nem. A FUD-ot már igen.

    "Egyebkent amit irok az tobbnyire igaz."
    Hát ez az, hogy ez műszaki fórumokon nem túl nyerő. Amiről nem tudsz pontos infót, arról inkább ne beszélj, találgatásokat ne írj le tényként, stb.

    "Ha esetleg tevednek, akkor korrigalast varnek el nem sardobalast."
    Láttam a HW-n a vitátokat, nem úgy tűnt, hogy nagyon hallgatsz másokra... (Legyenek azok akár játékfejlesztők pl.) Az SG-n sem igazán foglalkoztál a reagálásokkal (nevezetesen ott az enyémeimmel), csak leírtál pár dolgot, aminek kb. a fele volt igaz, aztán szépen továbbálltál - aztán újra.

    "Ez az alap illem egyik fontos pontja fuggetlenul attol hogy ki mennyire ideges."
    Talán nem neked kellene előírni a netes viselkedési szabályokat, hanem a meglévőkhöz kellene alkalmazkodni.

    "(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)"
    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?

    "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.

    "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.

    "Generacionkent 2x-ezodik a teljesitmeny. Ma a 4 magos cpu-knal jarunk, ez mar eleve 4x-es teljesitmeny."
    Csakhogy ez még koránt sem mainstream, így pl. a játékfejlesztők nem építhetnek erre. Majd még 1-2 év múlva.

    "Egy mai x86-os munkaallomas 8 maggal dolgozik. (2x4)"
    Egy Celles meg 2 Cellel (2 PPE + 16 SPE), ami mat. szám. telj.-ben 6-8x gyorsabb, mint a te 8-magosod. Vagy ott van az IBM QS20-asa, 24db Cellel.

    "A leggyorsabb mai gyarhato hagyomanyos cpu 10Ghz-es, ez az ibm power magos processzora."
    Ez egy igen drága szerver proci, és az egyszerűbb felépítése miatt nem annyival gyorsabb a korábbi Powereknél, amennyivel magasabb az órajele.

    "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."
    Nem olyan biztos, mert akkor sem feltétlenül lesz ez mainstream. PS3-ból viszont elég sok lesz addigra. Más területeket illetően, a Cellt is fejlesztik. Adott tranzisztorszámból a Cell mindig jóval többet fog kihozni.

    "(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."
    Viszont a 80-magos Intel sem feltétlenül a lustább programozók álma lesz.
    szerk: ja, és miért is (lenne) jobb a "rendes ddr", mint az XDR? (Nem keversz egyébként valamit? Jelenleg az SCC-ben lehet DDR memvezérlő, másodlagos ramnak, és framebuffernek.)

    "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."
    Futnának, de nem valami gyorsan. Hatékonyabb maradna rendesen az SPE-nek megfelelően kódolni.

    "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.

    "Persze a programozasi stilus nagyon megvaltozna, az spe leginkabb a sun niagara sorozatara hasonlitana."
    Ahhoz egyéb dolgokat is meg kellene változtatni.

    "Programozni ugyanolyan nehez oket."
    Szerintem nem. Úgy tűnik, nem veszel figyelembe jópár megkötést és bonyolítást a GPU-k esetén.

    "A gf8800-asnal 1/16, ati-n 1/8-ad."
    Nem egészen: a scalar adatokkal való műveletvégzés önmagában nem jelent gondot. Abból van gond, ha ezt nem tudod megtenni 8/16 szállal egyszerre.

    "Amennyivel jobb egy proci vektorfeladatokra, annyival benabb elagazasos logikanal."
    Ezért arany középút a 4-way SIMD megoldás, amit pl. az x86-os procik SSE-je is használ, vagy a Powerek VMX-e.

    "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."
    Hát azért ennek sem végtelen a kapu-száma (és tudtommal nincs kapu szintű fejlett energiagazdálkodás). Kapcsolási sebességben is lassabb.

    "Lehet jobb cpu-kat is kesziteni, mint a cell."
    Rajta.

    "En szemely szerint az intel megoldasaban latok nagy jovot, felteve hogy ossze tudjak hozni."
    Hát igen, az még a jövő zenéje, a Cell meg évek óta létezik.

    "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."
    Ez dícséretes, de most minek is írtad le? Tudod, aki dolgozik, pl. valamilyen fejlesztő, az az évek alatt összehoz ezt-azt.

    "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)"
    És ez most hogy jön ide? PS3-on is megteheti (majd) egy cég, hogy kész motort vesz. Viszont a motorfejlesztőknek el kellett sajátítani jópár újdonságot eddig is.

    "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."
    Ha így is van, némi asm keretrendszert kell elkészíteni, a többi már mehet sima c-ben.

    "Igy a legtobb dma muvelet blokkolja az spe-t, a helyett hogy az masik task-ra valtana."
    A másik taszk csak az egyik lehetőség, a másik - sűrűn alkalmazott - a dual-buffering.

    "Mondjuk en fordito tamogatasa nelkul is meg tudnam irni assembly-ben"
    Nem vagy egyedül.

    "de a legtobb jatekot es tudomanyos programot ma mar nem assembly-ben irjak. Egyszeruen nincs ra ido."
    Nem is kell az egész kódot asm-ben írni.

    "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."
    Sorolnád őket?

    "(ezert van olyan keves ps3 exkluziv jatek)"
    Elsősorban nem ezért.

    "Ahol hasznaljak ott is tobbnyire az ibm vagy a sony kolcsonadott mernokei kodolnak az spe-kre."
    A többség vacak játékokat készít úgyis. Akik normálisabbakat akarnak, azok meg tudják ezt maguk is.

    "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."
    Csúsztatás. A legtöbb multiplatform játék kijön PS3-on is.

    "Igen, vegulis minden el kell hogy ferjen 256Kbyte-ban. Egy mai atlagos 1024x1024-es terkep pedig 1 Mbyte. :-)"
    Az a 3. esetbe tartozik, de van sok 2. eset is.
    Egyébként meg nem feltétlenül 256KB-ban, ha több SPE is dolgozik rajta, akkor annyiszor 256KB.

    "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)"
    Régebbi kódok portolásánál jelentkezik ez a probléma (ami azért többé-kevésbé áthidalható), az új kódokat meg eleve ezt beleszámolva fejlesztik.

    "A wii-bol meg tobbet mint a masik kettobol, pedig nem sok elonye van."
    Ezzel most azt akarod mondani, hogy az Xbox360 is népszerűtlen?

    "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)"
    És most itt szerinted milyen relevanciával bír ez?

    "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."
    1. A PS3 a Cell piacának csak egy része.
    2. Te egy jétékfejlesztői csapat főnöke vagy? Nem? Akkor miért is akarod előírni, hogy mások mivel foglalkozzanak, és mivel ne? Majd mindenki szépen eldönti magának.

    "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."
    Hát akkor te ne foglalkozz vele...

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz kvp777 #71 üzenetére

    Hát, "lezárod" vagy sem, azért én válaszolok, mert megint elhangzott néhány "érdekes" állítás. Egyébként meg annyian beszélgetnek egy topikban, ahánynak van hozzáfűznivalója.

    "Egy egyszeru es olcso konzol lenne, ami a leheto legjobban hasonlit egy atlag windowsos pc-re"
    Huh, hát ez meg a lehető legtávolabb áll a valóságtól! Ha így lenne, akkor egyfajta HTPC lenne, x86 procival, PC-s architektúrával. Ehhez képest:
    1. x86 proci helyett 3-magos spéci PowerPC, fordított endianess-szel.
    2. Semmi köze a PC-s architektúrához (cpu+ddr main ram+NB[+SB] - AGP/PCIe busz - gpu+vram): unified ram, vram alapon (nagy latency); proci és gpu között nem szabványos busz, stb.
    3. GPU mellett EDRAM.
    4. GPU senem szabványos DX9, senem szabványos DX10, hanem a kettő között.

    Annyi közük van egymáshoz, hogy portoltak rá egy Windows kernelt, és egy DirectX-et. Meg gondolom egy Visual Studiot.

    "de sajnos annyira olcsora akartak csinalni, hogy kisporoltak belole a rendes hutest."
    Nyilván nem szándékos volt, hanem méretezési hiba. Egy kicsivel nagyobb borda semmiség lett volna.

    "de ps3-ast sem mert nincsen ra olyan jatek ami miatt nekem szemelyesen megerne, linux alatt meg le van tiltva a 3d gyorsitas."
    Ez változóban van... A második is. Ugyanis nincs letiltva, csak nincs hozzá API szolgáltatva. [link]

    "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."
    Ez kb. az utolsó szempont etekintetben. A vram alapú unified memory nem fejlesztéskönnyítési megoldás volt, hanem olcsósítási. (Főleg, hogy így a proci magasabb latencyjű memóriával kénytelen dolgozni.) Ráadásul a PC-s fejlesztők is éppenhogy az osztott memóriához vannak szokva.

    "Ennek hasznalata megfelelo implementacio mellett automatikusan optimalizalt vektoros/simd kodot eredmenyezne a template altal tamogatott muveletekre."
    Az IBM Octopiler compilere is képes erre.

    "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."
    Semmiből sem áll megírni, akár makrókkal.

    "A c++ inkabb a grafikus motorra igaz. Pl. directx-et nem is nagyon erdemes mashogy programozni, mert az api c++-os."
    Érdekes logikai bukfenc van itt. Tehát azért kellene Cellre (ill. PS3-ra) c++-os SPE fordító, mert az Xbox360-on DirectX van!?

    "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."
    Akik nem tudják használni, normális játékprogramot (ill. motort) sem képesek írni...
    Mellesleg PS3-on egy egyszerűsített, játékorientált OpenGL van.

    "Sokkal olcsobb. Az eloadason is ez volt az egyetlen pozitivuma."
    Akkor meg? Ez csak PC-nél fő szempont, munkaállomásoknál, mini- és szuperszámítógépeknél, és konzoloknál nem. (Utóbbi esetben a megfelelő gyorsaság, tehát a Cell rendes kiszolgálása sokkal fontosabb, mint az ár. DDR2-ből persze 2x annyi lehetne a PS3-ban, de a teljesítményt meg megfelezné.)

    "En szemely szerint inkabb gddr-t raknek a cpu ala is."
    Jó nagy butaság lenne...

    "Tehat fogjuk a 256KB lokalis ram-ot. [...]"
    A leírt megoldás kényelmesebbé tenné a dolgokat, de a teljesítménynek enyhén szólva nem tenne jót.
    "Sajnos nem, mert a jelenlegi fordito nem tud relocatable kodot gyartani. Hiaba van keretrendszer ha a modulok agyonutik egymas regisztereit es memoriacimeit."
    Nem is kell, taszkváltásnál cserélődik az LS tartalom. Vagy te 256KB-on belül akarsz taszkot váltani? Eddig arról beszéltél, hogy egy rutin számára is túl kicsi.

    "(lasd: feature request)"
    Hol?

    "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."
    Jópár meg PS3-exkluzív lesz. És van egy olyan érzésem, hogy ezek jobbak lesznek.

    "Annyival, hogy a kedvenc jatek kategoriaimbol 1 darab jatek sincs ps3 ala. Igy egyszeruen nem lenne mivel jatszani ha vennek egyet."
    Ez a te egyéni szoc. problémád.

    "Az emberek nem azert nem veszik mert draga, hanem mert nincs ra eleg jatek."
    Még1x mondom: átlagosan annyi fogy belőle, mint az Xbox360-ból (bár az utóbbi hetekben megtolta az eladásokat a Halo 3, viszont PS3-ból most jött ki az olcsóbb változat, és még idén jön néhány várt játék). Akkor tehát az Xbox360-at sem veszik?

    "Csak erdekelnek az uj architekturak, legyenek azok jok vagy rosszak. Eleg sok rendszerre fejlesztek egyszerre, erdemes latni mibol lehet valogatni."
    Ezen kicsit túlmutatni látszik az aktivitásod és viselkedésed. Konkrétan mintha fizetett FUD-ügynök lennél. Jelen hsz-ed is csak ezt erősíti.

    [ Szerkesztve ]

Új hozzászólás Aktív témák