Hoppa! Most mar tenyleg nagyon kivancsi vagyok, mit fognak kihozni a PS3bol, bar nem vagyok egy konzolos arc.
Aut inveniam viam aut faciam.
Gyorskeresés
Legfrissebb anyagok
Szakmai témák
PROHARDVER! témák
Mobilarena témák
Általános témák
GAMEPOD.hu témák
Hirdetés
Útvonal
Fórumok » Processzorok, tuning » [Re:] Nyilvánosan demonstrálta a Cell képességeit a ToshibaHozzászólások
Loha
(PH! kedvence)
Tényleg elég XP-nek néz ki a az az oprendszer...
Az oké, hogy 48 MPEG2-őt le tud játszani egyszerre, de mi van ha csak egy szál fut egyszere ki tudja használni a proci képességeit?
Mindenestre nagyon nyálcsorgató proci... 
[Szerkesztve]
Ne butaskodjatok, hogy hasznalnanak mar Windowst? x64-re is alig akart kijonni, Cellhez meg total at kellett volna irni.
A kepen az latszik, hogy egy windowsos gepen WMP-vel lejatszak azt a videot, ami a videot lejatszo celles geprol keszult (vagyis igazibol meg mindig senki nem latott Cellt, csak egy videot rola)
Falsus in uno, falsus in omnibus.
Idézet a cikkből:
''A Toshiba olyan – közelebbről meg nem nevezett, de a kép szerint Windowsnak látszó – operációs rendszert használt, amely több taszk vagy többszálú kódok futtatása esetén maga gazdálkodik az erőforrásokkal, és nem igényli az alkalmazások programozóitól az egyes végrehajtási egységek megcímzését.''
Tehát ha win, és a proci képes x86-ként futni, akkor elképzelhető. ha meg saját oprendszer (neadjisten Linux), akkor meg xp-style skint gyártani nem nagy kunszt hozzáértők számára.
ez olyan, mint a görögtűz, csak görögvíz - Loretto
Hat, ha csak egy szal van, akkor az nyilvan csak egy procin fut. Ez egy ilyen 
Viszont errol tudnak a programozok is, akik majd biztos ovakodnak attol, hogy csak egy thread (bar szerintem inkabb kulon processek lesznek, a threadekkel csak a szivas van, ha a Windowsban sikerult volna normalis sebessegu context switcheket csinalni, akkor senki sem hasznalna oket )
Falsus in uno, falsus in omnibus.
Olvasd mar el meg egyszer, amit irtam
Nem, a Cell nem kepes x86-kent futni, es nem Windows, de meg csak nem is Linux, hanem vmi speci Toshiba fejlesztesu OS fut rajta.
Skint meg tutira nem gyartottak ra, mert szerintem grafikus felulet sincs, amire lehetne skint gyartani.
Falsus in uno, falsus in omnibus.
Loha
(PH! kedvence)
De most akkor a toshiba pikk-pakk összedobott neki egy OS-t?
janpotocki
(VIP)
minden bizonnyal igazad van.
Alec
(kvázi-tag)
miért pikpak könyörgöm? szerinted a cellt három hét alatt hozták össze?
Hat, ha ossze birtak hozni egy ilyen gepet, akkor az mar igazan nem tul sok - foleg, hogy alapjaba veve egy OS-t osszehozni nem tul nagy melo, az egeszbol a legizgalmasabb resz az lehetett, amikor a processeket elosztjak a processzorok kozott, azt meg mindenfelekeppen meg kellett irni.
Falsus in uno, falsus in omnibus.
Bocs, valóban flreértelmeztem...
Először úgy értettem, hogy maga a proci osztja szét a taszkokat. aztán leesett, hogy a procira írt oprendszer. Egy procit mindenféle oprendszer nélkül megcsinálni elég érdekes lehet, hogyan tesztelik, ha nincs mivel? 
amúgy mint elvakult Linux-fan kérdezem én, hogy miért kellene mindent az alapoktól kezdeni, mikor már egy könnyen hozzáférhető alap van? 
ez olyan, mint a görögtűz, csak görögvíz - Loretto
faster
(PH! nagyúr)
A processek közötti gyors kontextusváltás nemcsak a windowsban nem sikerült összehozni, hanem más oprendszerekben sem olyan egyszerű, nem véletlen, hogy a Linuxban is megjelentek a threadek. Ráadásul az adatcsere sem olyan egyszerű szeparált processek között.
L3zl13
(PH! nagyúr)
Ha nincs grafikus felület, akkor mi generálja az ablakot, amiben a videó fut?
A CELL részben IBM fejlesztés, Power procikhoz hasonló központi egységgel ha jól tudom. Azon meg MacOS X-et használnak, ami szintén egy linux. Szvsz könnyen lehet, hogy valami linux alapú cuccot használnak.
Szerk: OK. #3-at elolvastam.
Akkor viszont nem volt egy nagy demonstráció, akárki csinálhat olyan avi-t amin látszólag 256 videó fut egyszerre. 
[Szerkesztve]
Aki hülye, haljon meg!
faster
(PH! nagyúr)
Egy pc.
Gregorius
(őstag)
Ekkora méretű (durván 240*144 körüli?) szegmensekből egy szimpla egymagos mai asztali processzor is csuklás nélkül kikódol 8-12-őt folyamatosan (meg amennyivel többet, ha meg van fejelve HT-vel). A videó dekódolás viszont egy igen nagyon jól párhuzamosítható feladat (a képfeldolgozás is, és az egyes kodekek és filterek is aszinkron futnak), ezért a cellnek ennél a 48-nál jóval többet kellene teljesítenie ''hazai pályán''. Szóval még ennyire béta és azért nem nyomtak ki belőle többet, vagy valami nagyon el lett rontva?
''As long as they're going to steal it, we want them to steal ours'' -- Bill Gates, 1998 ''If they're going to pirate somebody, we want it to be us rather than somebody else.'' -- Jeff Raikes, Microsoft Business Division, 2007
Linuxban a threadek inkabb a megosztott memoria miatt van (ami alapjaba veve a szopas forrasa, viszont alkalomadtan jol johet), nincs lenyeges kulonbseg a ketto kozott teljesitmeny szempontjabol, kb mindketto olyan gyors, mint NT-n a threadek
Falsus in uno, falsus in omnibus.
A MacOS X nem Linux, hanem BSD (konkretan FreeBSD) alapu.
[Szerkesztve]
Falsus in uno, falsus in omnibus.
janpotocki
(VIP)
az mpeg 2-streamek eredetileg sdtv felbontásúak voltak, az egyik spe skálázta őket az adott felbontáshoz, és így sem használták ki a teljes processzort. amúgy a cell képességeinek megítélésével szvsz várjunk még, ez csak egy demó volt...
Loha
(PH! kedvence)
3év is pikk-pakknak számít szerintem, ha a nulláról kell összedobbni egy oprendszert.
A kepen nem a CELL altal produkalt real-time video lathato egy az egyben, hanem egy ebbol keszitett WMV HD video amit a Windows Media Player-al jatszottak le...
Privat velemeny - keretik nem megkovezni...
Gregorius
(őstag)
Javíts ki, ha tévedek, de az mpeg-2 képtömörítése progresszív, azaz ha gyengébb minőséget (kisebb felbontást), kisebb pontosságot akarsz, akkor egyszerűen csak addig kell dekódolni a makroblokkokat, amíg a kívánt részletesség előáll, a bemeneti adat maradéka eldobható.
''As long as they're going to steal it, we want them to steal ours'' -- Bill Gates, 1998 ''If they're going to pirate somebody, we want it to be us rather than somebody else.'' -- Jeff Raikes, Microsoft Business Division, 2007
Loha
(PH! kedvence)
És akkor miért nem lehetett ezt a videót letölthetővé tenni, és miért nem lehetett csinálni egy normális képet?
bujdyka
(tag)
Szerinted?
Ha minden fasza lenne, és a Cell holnap debütálna, akkor hidd megtették volna...
Úgy tanul a gyerek, ha kérdez...
Viktor77
(MODERÁTOR)
Ha jól tudom a Cell a PS3-ban debütál.
Van még ideje, a pc még akkor is ''lassú'' lesz, ha ez kijön.
Bazinga!
Én is úgy tudom, hogy egy blokk ''átlagos színét'' gyorsan ki lehet ''kapni'' ez MPEG2-ből, tehát ha megfelelő méretre lekicsinyítve (jó arányúra, tehát nem torzítva, és nem mondjuk 98%-os méretre) kell csak lejátszani, azt sokkal gyorsabban meg lehet tenni, mintha teljes felbontásban játszanánk le. Persze ehhez az kell, hogy minden pont jól jöjjön ki, viszont egy direkt erre készített videonál ezt könnyen meg lehet tenni. Így már 48 ilyen video lejátszása nem tűnik valami hatalmas teljesítménynek, gyakorlatilag alig több, mint egy 1920x1080-as MPEG2 lejátszása lenne, max a vinyót gyilkolja jobban (persze azért ez se gyenge, meg talán az MPEG2 nem is tud ekkora felbontást). Mondjuk azt állítják, hogy az egyik ''mag'' végezte az átméretezést, tehát lehet, hogy nem trükköztek.
Nem akarom leszólni a Cell-t, mert igencsak nagy teljesítmény várható tőle, de valószínüleg még csak olyan állapotban van (vagy még olyanba se), mint az Athlon64-ek, amikor a megjelenés előtti zártkörű bemutatókon 600MHz-en mentek.
\\\\\\\\\\\\\\\\ ALLEZ AMÉLIE!!! - www.ameliemauresmo.hu //////////////// Videókazetták digitalizálása Xvid és DVD-Video formátumba olcsón, jó minőségben! Ha érdekel dobj privit!
arty
(senior tag)
én ilyen winyot akarok, ami 48x4-8mbites videot folyamatosan tud szolgáltatni a prociknak ... biztos jól ''defragolták'' őket előtte ;)
sztem valami kamuság tuti volt ebben .... máketing.
A szálakkal csak szívás van? Hm? A processzeket jóval nehezebb váltani (lasabb), meg a szálaknak jóval kisebb leíró memória kell, hülye az, aki a processzeket előnyben létesíti a szálakkal szemben!
Tévedsz. Az MPEG2 fix méretű (16x16-os) makroblokkokat használ, a képet ekkora négyzetekre bontják fel. Egy makroblokkot kibontani mondhatni elemi művelet, nem lehet olyat, hogy csak 4x4-es területet bontok ki, és akkor 4-ed a felbontás mindkét irányban.
Simán tud 1920x1080-at.. A 3200x2400-as HDTV-ket szerinted mivel tömörítik? Max ez vagy az az implementáció nem kezeli, de a szabványban nincs semmilyen felső határ. Max az xy bites szélesség szám maximális értékénél, értsd 2^32 - 1
Egyébként végiggondolva, szerintem nem több meló 16 darab x*y felbontású videót lejátszani, mint egy darab 4x*4y felbontásút: a meló az inverz DCT-ben van, és mindkét esetben ugyanannyiszor kell ezt elvégezni..
Ha 48 db SDTV-t játszottak le, ami olyan 720x480 felbontás, akkor az egy folyamban olyan, mintha 5760x2880-as felbontású videót játszottak volna le. Hááát, annyira nem érzem túl nagy számnak..
[Szerkesztve]
Bővebben: link
[Szerkesztve]
Privat velemeny - keretik nem megkovezni...
Gregorius
(őstag)
Tudtommal úgy van, hogy kódolásnál 16x16-os blokkból csinál DCT-vel egy szintén 16x16-os blokkot, ami az oszlop/sor alapján a megfelelő ''hullámhosszú'' komponens amplitúdóját kódolja a megfelelő kvantálással. Ráadásul a legelső (1. sor, 1. oszlop) komponens ''nulla frekvenciás'', azaz a 16x16-os blokk átlagszíne/fénye/stb, tehát ha pont 16-odára kicsinyítünk mindkét irányban, akkor az egész IDCT megspórolható. Ha az a 16x16-os blokk a valóságban csak 2x2-esnek látszik mondjuk, akkor nyilván nem kell az (eredetiben) 1-2 pixeles hullámhosszokat dekódolni, mert elhanyagolható (szimmetrikus esetben nulla) korrekciót adnak egy-egy pixelhez.
Valahogy így (ez egy jpeg 8x8-as bázisfüggvény-táblája, de az elv ugyanaz).
Bővebben: link
''As long as they're going to steal it, we want them to steal ours'' -- Bill Gates, 1998 ''If they're going to pirate somebody, we want it to be us rather than somebody else.'' -- Jeff Raikes, Microsoft Business Division, 2007
''...akkor az egész IDCT megspórolható.''
Most oszinten - ilyet hogy irhatsz le ha MPEG dekodolasrol van szo ?
Egyebkent LordX-nek igaza van es a Toshiba szerint is a bemutatott szoftrver megoldas arra van hogy Preview kepet csinaljon sok csatornabol egyszerre. A hasznalt chip maga szinten csak 1 db 1920x1080-as HDTV felbontasu videot tud feldolgozni es megjeleniteni.
Privat velemeny - keretik nem megkovezni...
Jim Tonic
(PH! kedvence)
Ha ez annyira jó processzor lesz, nem kizárt, hogy megjelenik majd a számítástechnikában. Más nem, a Mac gépeiben kicsit átdolgozva.
de mindegy, van különbség az átlag fészbuk user meg a terrorista között... az utóbbival lehet tárgyalni... (C) bambano
Bocs, programozo vagyok. Az, hogy ket ciklussal tovabb tart a valtas (mondjuk Linuxon talan meg ilyen kulonbseg sincs, hiszen itt a process rendszert hekkeltek meg, hogy legyen thread-szeru viselkedes (legalabbis ugy 2.4 tajaig)) meg hogy harminc byte-tal tobb memoria kell neki, az nem nagyon erdekel.
Az viszont, hogy a threadek kozosen turjak a memoriat es ebbol mindenfele rejtelyes, nehezen reprodukalhato es javithato hibak keletkeznek - na EZ mar zavar.
[Szerkesztve]
Falsus in uno, falsus in omnibus.
Gregorius
(őstag)
Most oszinten - ilyet hogy irhatsz le ha MPEG dekodolasrol van szo ?
Nem értelek. Vagy te nem értesz. (végülis mindegy, az eredmény ugyanaz: nem értjük egymást). A mondat egyébként úgy kezdődött, hogy ''Ha...''.
MPEG kódolás: DCT-vel. Ez nem spórolható meg. MPEG dekódolás IDCT-vel. A makroblokk bal felső eleme (az az 1 db a 256-ból) viszont nem IDCT-vel, hanem egyszerű prediktív (DPCM) kódolással megy az (időben és térben) előző blokkokhoz képest.
''As long as they're going to steal it, we want them to steal ours'' -- Bill Gates, 1998 ''If they're going to pirate somebody, we want it to be us rather than somebody else.'' -- Jeff Raikes, Microsoft Business Division, 2007
PetX
(fanatikus tag)
Én nem értelek benneteket, miért vitatkoztok mikor még ki sem jött a proci és tényleg nem lehet tudni, hogy mire képes.
Amúgy meg nem biztos, hogy egy videó dekódolásra kihegyezett procin jobban fog menni a Counter-Strike Source 
Addig meg nem érdekel, CS 4EVER ! 
C2D E8400, Gigabyte EP45-UD3R, Sapphire Radeon HD6950 2GB, 2x2GB 1066MHz, 64GB SSD+500GB+500GB+250GB(linuxnak:), SAMSUNG SH-S223F DVD-RW. + RAZER-Logitech-Gigabyte-SAMSUNG-BMW FAN xD
A mozgáskompenzációt nem számoltad bele. Igen dúrván el tudná cseszni a képet az általad leírt csökkentett felbontású dekódolt képre próbálnád alkalmazni a nagyobb felbontású által kiszámolt mozgáskompenzációt.
Jo, felejtsuk el a ''Ha..''-t.
A 48 stream 6 sor 8 oszlopra volt osztva 1920x1080-as felbontasban. Ez azt jelenti egy darab 240x180-as volt. Mivel japanrol es a Toshibarol van szo igy az emlitett SDTV jel egy 720x480-as felbontasu NTSC stream volt.
720x480 -> 240x180 esetben nem all fent az elmeleted. A stream dekodolva kellett hogy legyen.
A kepet nezted amit linkeltem ?
Privat velemeny - keretik nem megkovezni...
A 16x16-os kicsinyítást tényleg meg szokták csinálni, az előnézeti kép jellemzően a DC komponens kivetítése, felskálázva. De ez az előbb említett MC miatt roszabb, mintha egyszerűen 16x16-al kicsinyített képet rajzolnál ki egy normális dekódolás után.
Nem éppen 30 bytetal kell neki több, néha egy egész lapot kell cserélni, ha olyan a program. (A szálaknál csak a regiszterek + stack - ami egy pointer - kicserélendő, a processznek meg még van extra adminisztrációja e felett, most hirtelen nem tudom, nem néztem utána.) És ez nagyon nem mindegy, ez már lehet nagyon lassú. Ha meg több szálad/processzed van, az osztott memóriától bármilyen különböző kommunikációs mód nagyságrendekkel lassabb.
Ezt ertem, de a jelen esetben ez lehetetlen, a kapott previewstream-ek tul kicsik lettek volba. Ha a kollega hozzaszolasa egy kisse off-topic es altalanos dekodolasi diskura resze volt akkor elnezest. En ugy ertettem szorosabban kapcsolodik a hirhez.
Privat velemeny - keretik nem megkovezni...
Viktor77
(MODERÁTOR)
Nem videódekódolásra van kihegyezve, csak a demonstráció volt ez.
Magánvélemény: Ez az a proci, amitől az egész pc-s társadalom kidobja a gépét az ablakon. Remélem.
Bazinga!
Magánvélemény: Majd ha a pogramozók megtanulnak programozni egy erősen asszimetrikus többmagos rendszert, azaz soha..
A cellben sok, egymástól eltérő, más feladatra kihegyezett, kis komplexitású mag van, nem szeretnék rá C fordítót írni, asszem..
[Szerkesztve]
Gregorius
(őstag)
A mozgáskompenzációt nem lehet ugyanúgy leskálázni? A hivatkozott blokk ugyanúgy megtalálható az előző képkockán, legfeljebb kisebb (de egy az egyben hozzáadható az IDCT végeredményéhez), és csak az elmozdulásvektort kell átméretezni.
Szerk: ez most már inkább off.
[Szerkesztve]
''As long as they're going to steal it, we want them to steal ours'' -- Bill Gates, 1998 ''If they're going to pirate somebody, we want it to be us rather than somebody else.'' -- Jeff Raikes, Microsoft Business Division, 2007
Viktor77
(MODERÁTOR)
Nézd. A PS2 Engine se volt valami egyszerű, el is telt pár év mire megtanulták rendesen programozni, de megy.
Bazinga!
A processzvaltast Linuxon sikerult megcsinalni normalis sebessegure, innentol kezdve nem aggodok miatta Osztott memoriat meg ket processz kozott is lehet hasznalni, ha muszaj (hasznalnak is, pl az X-nel a MIT SHM extension), de ott csak egy bizonyos memoriaterulet lesz kozos, nem minden (ami erosen csokkenti a hibalehetosegek szamat), de egyebkent pl a socketek sem olyan veszesen lassuak.
Amugy meg az egeszrol az fdiv bugos idokbol szarmazo vicc jut eszembe (csecsemoknek:
Egy AMD proci beszelget egy Pentiummal:
- Mennyi 2+2?
- Ot.
- Rossz valasz.
- De gyors volt, nem?)
Raadasul, ami eleg azert lenyeges, a threadek osszes elonye elvesz, ha a ket thread ket kulon processzoron fut, amire azert Cellnel eleg nagy esely van.
Falsus in uno, falsus in omnibus.
Nem az elmozdulásvektor mérete a problémája, hanem hogy a kisebb felbontásban másra hivatkozik, mint kéne, és a hibát megint kisebb felbontásban dekódolod, úgyhogy így négyzetesen nő a zaj..
Nem hiszem, hogy a cell operációs rendszerén nem lehet majd 32-nél (vagy amennyi egység van a prociban) több darab szálat/processzt futtatni
Úgyhogy a környezetváltás az ugyanúgy megmarad, csak 32-szer kevesebbszer kell lefuttatni..
Hát, a PS2 processzora egy mezei RISC processzor, azért ilyet már használtak egykét helyen..
